Удаление / аннулирование подходов для справочных данных - PullRequest
1 голос
/ 20 марта 2011

Основываясь на обсуждении, которое я нашел здесь: База данных: удалять или не удалять записи , я хочу сосредоточиться на справочных данных, в частности, добавить несколько соображений по этому поводу и спросить, какой подход вы предпочитаетев целом, или на основе того, по каким критериям вы принимаете решение, какой из доступных подходов вы выберете.

Давайте предположим следующую структуру данных для «базы данных запросов» для клиентов, тогда как запросы могут доставляться по различным каналам.(телефон, почта, факс, ...; наша «таблица справочных данных, на которой я хочу сосредоточиться»):

Request (ID, Text, Channel_ID)
Channel(ID, Description)

Давайте для начала предположим следующие данные в этих двух таблицах:

Запрос:

ID    | Text                                         | Channel_ID
===============================================================  
1     | How much is product A currently?             | 1 
2     | What about my inquiry from 2011/02/13?       | 1
3     | Did you receive my payment from 2011/03/04?  | 2

Канал:

ID    | Description
===============================================================  
1     | Phone
2     | Mail
3     | Fax

Итак, как вы можете атаковать это, принимая следующие требования:

  1. Каналы могут меняться со временем.Это означает: их описания могут измениться.Могут быть добавлены новые, только действительные, начиная с определенных данных.Каналы могут быть признаны недействительными (к определенной дате)

  2. Для целей отчетности и мониторинга необходимо иметь возможность определить, по какому каналу был первоначально подан запрос.

  3. Для новых запросов должны быть разрешены только действующие в настоящий момент каналы, тогда как для ранее существующих также должны быть разрешены каналы, действовавшие на эту конкретную дату.

В моем понимании, это явно требует более богатого подхода к аннулированию, который выходит за пределы флага удаления, возможно, что-то, включающее подход 'ValidFrom / ValidTo' для таблицы справочных данных.

С другой стороны,это связано с рядом трудностей при захвате данных запросов, потому что для новых запросов вы отображаете только те каналы, которые в настоящее время доступны, а для обслуживания уже существующих каналов должны отображаться все каналы, доступные на момент создания этой записи.Это может быть не только сложно с точки зрения разработки, но также может быть не интуитивно понятным для пользователей.

Как вы обычно настраиваете свою модель данных для справочных данных, которые могут со временем измениться?Как вы создаете свой пользовательский интерфейс тогда?Какие дополнительные параметры вы принимаете во внимание для правильного проектирования базы данных?

1 Ответ

1 голос
/ 20 марта 2011

В таких случаях я обычно создаю другую таблицу, например, channel_versions, которая дублирует все поля из channel и имеет дополнительный столбец create_date (и, конечно, его собственный PK). Для channel я определяю после вставки / обновления триггеры, которые копируют новые значения в channel_versions. Теперь все запросы из таблицы Request относятся к записям из channel_versions. Для новых запросов вам необходимо получить самую последнюю версию канала от channel_versions. Для старых запросов вы всегда знаете, как выглядит канал, когда запрос был выполнен.

...