Изменения в данных и их влияние на исторические данные

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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