Подходы к удалению / недействительности для справочных данных

Question

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

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

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. Для новых запросов следует разрешать только в настоящее время «действительные» каналы, тогда как для ранее существовавших, также должны быть разрешены каналы, которые были действительными в эту конкретную дату.

В моем понимании, это явно запрашивает более богатый подход к недействительности, который выходит за рамки флага удаления, вероятно, что -то включает в себя подход «Validefrom / Validto» для таблицы справочных данных.

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

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

Answer 1

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