Исторические данные в бизнес-приложении

Question

До сих пор у меня была работа с несколькими базами данных, и философия была совершенно другой.Меня удивило,

Является ли хорошей идеей дублировать таблицы для исторических целей в бизнес-приложении ?

Под бизнес-приложением я подразумеваю: программное обеспечение, используемое предприятием для управления всеми его данными (например, счетами, клиентами, запасами [если применимо] и т. Д.)

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

Плюсы:

Использование исторических таблиц может ускорить исследования с использованием фактически используемых данных, поскольку это делает ваши фактически используемые таблицы меньше.1016 * Лучшее разделение исторических и фактических данных

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

Минусы:

Сделайте вашу базу данных в 2 раза больше таблиц.

MakeВаша база данных более сложная

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

Answer 1

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

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

Ни одно из этих решений не так уж и приятно - архивные таблицы означают множество дублированных кодов / данных, сложные архивные процедуры (особенно с отношениями с внешним ключом), много возможностей для ошибок.

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

Что касается ваших профи:

В общем, я не думаю, что вы заметите влияние на производительность, если толькоВы говорите об очень, очень крупных предприятиях.Я не думаю, что в современных решениях для SQL-серверов вы заметите разницу в скорости между запросом 10 000 записей клиентов или 1 000 000 записей клиентов.

Определение «исторического» на самом деле довольно сложно - большинство предприятий вынуждены хранить исторические данные для целей регулирования и налогообложения, часто в течение многих лет;они, вероятно, захотят иметь возможность анализировать тенденции за несколько лет и т. д. Если бизнес хочет видеть «сколько виджетов мы продавали в месяц за последние 5 лет», это означает, что вам нужно хранить данные за 5 лет.каким-то образом («сырым» или предварительно агрегированным).

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

Answer 2

У меня была бы только «дублирующаяся» таблица типов для хранения исторических ВЕРСИЙ каждой записи, например, журнала изменений.Даже журнал изменений не является дубликатом, так как он должен был бы иметь информацию о том, когда он был изменен и т. Д. Как правило, я бы не рекомендовал переносить строки из активной в историческую таблицу.Вам придется управлять разными версиями запросов, чтобы найти данные в двух местах!Используйте статус, чтобы контролировать возможность изменения данных.Я мог видеть, что это может быть сделано, если есть определенные обстоятельства для конкретного применения.Как только вы начинаете добавлять внешние ключи, становится трудно удалить данные.Если у вас было действительно корпоративное бизнес-приложение и вы пытались удалить счета-фактуры, у вас возникают всевозможные проблемы с FK для других таблиц, кредиторской / дебиторской задолженностью, затратами на сырье, доходами от продаж, информацией о доставке и т. Д.