Изменения в данных и их влияние на исторические данные - PullRequest
1 голос
/ 12 ноября 2011

Скажем, у вас есть простая система CRM с клиентами и заказами.Если клиент меняет свое имя, вы предпочтете, чтобы старые исторические заказы также получили новое имя, или вы копируете его в строковое значение в заказе, чтобы сохранить точность?

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

Рад слышать, что вы думаете ...

(Если этот вопрос относится к другому месту, пожалуйста, укажите путь ...)

1 Ответ

2 голосов
/ 12 ноября 2011

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

Обычно я использую мысль, что если она может быть напечатана, она должна быть печатается позже и поэтому не должно меняться.

Это неплохое начало. Но некоторые печатные издания, как ожидается, со временем изменятся. Телефонные книги, справочники, адреса для выставления счетов. Вы хотите разрешить изменение столбцов, содержащих «текущий адрес выставления счета», но не хотите, чтобы столбцы, содержащие «адрес выставления счета на момент заказа», изменились. Вы хотите, чтобы «текущая цена» изменялась с течением времени, но «цена на момент заказа» не должна меняться со временем.

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

Если вы позволите «цене во время заказа» изменяться со временем, вы измените итоговые суммы заказа с течением времени - что-то, я уверен, что ваши бухгалтеры расстроятся.

Существует несколько способов предотвратить изменения исторических данных.

  • Не используйте ссылки на внешние ключи, которые каскадно обновляют или удаляют. Это практически всегда требование. Можно ли вообще использовать ссылки на внешние ключи, зависит от приложения.
  • Пусть пользовательский интерфейс заполняет такие вещи, как "адрес для выставления счета на время заказа ", возможно, путем выбора и копирования из таблицы адресов для выставления счетов клиентам. Это не дублирует данные, во всяком случае, не в реляционном смысле. Повторяющиеся данные означает" одинаковые значения с одинаковым значением ". ". Когда вы копируете текущий адрес выставления счета в столбец" Адрес выставления счета во время заказа ", вы меняете его значение.
  • Метка времени ваших исходных таблиц. Таблица «биллинга клиентов» адреса могут, например, также содержать столбцы, которые означают «использовать этот платежный адрес для заказов, размещенных до или после этой даты» (a Дата начала) и "использовать этот платежный адрес для заказов, размещенных до this date "(дата окончания). Вы присоединяете заказы к этой таблице; дата порядка будет определять, какая строка была использована во время порядок (например, ...JOIN customer_billing_addresses c ON c.start_date <= orders.order_date AND orders.order_date < c.end_date...). Вам понадобится тщательный дизайн, чтобы гарантировать, что нет перекрытия периоды, и что удаление строк из адресов выставления счетов клиентам строго контролируется. (То есть почти полностью запрещено.)

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

...