Это хороший дизайн для таблицы аудита с тоннами записей?

Question

У меня есть таблица, которая отслеживает данные инвентаря по каждой отдельной части. Это упрощенная версия таблицы (исключены некоторые неключевые поля):

UniqueID,
ProductSKU, 
SerialNumber,
OnHandStatus,
Cost,
DateTimeStamp

Каждый раз, когда что-то случается с данным фрагментом, создается новая запись аудита. Например, когда мой продукт ABC впервые добавляется в инвентарь, я получаю следующую запись:

1, ABC, 555, OnHand, $500, 01/01/2009 @ 02:05:22

Если стоимость серийного номера ABC 555 изменяется, я получаю новую запись:

2, ABC, 555, OnHand, $600, 01/02/2009 @ 04:25:11

Если произведение продано, я получаю еще одну запись:

3, ABC, 555, Sold, $600, 02/01/2009 @ 5:55:55

Если новый кусок ABC принесен, я получаю эту запись:

4, ABC, 888, OnHand, $600, 02/05/2009 @ 9:01:01

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

Используя мой пример выше, если бы я хотел получить свою инвентарную стоимость для продукта ABC по состоянию на 01.02.2009, мне нужно было бы выбрать для каждой уникальной комбинации Product / SerialNumber одну самую последнюю запись до по 01/03/2009 со статусом «OnHand», а затем складываются расходы. (Я не уверен на 100%, как будет выглядеть этот оператор select, но я собираюсь немного поэкспериментировать).

Мои вопросы: это хорошая структура для типа таблицы аудита, которую я описываю? То есть, пригоден ли он для быстрых запросов при соответствующей индексации? (Я пытаюсь представить, что произойдет, когда эта таблица увеличится до миллионов строк.)

Стоит ли разбивать исторические записи в отдельную таблицу и оставлять только самую последнюю запись для каждой комбинации ProductID / SerialNumber в "активной" таблице?

Любые отзывы / предложения / комментарии / ссылки приветствуются.

Спасибо!

Answer 1

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

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

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

Answer 2

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

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

Answer 3

Во-первых, немного определения (не клинические определения, просто моя собственная номенклатура разделения идей):

==========

Исходная таблица: ежедневная таблица, к которой вы добавляете и извлекаете данные.

Таблица аудита: таблица, содержащая несколько версий любой записи в соответствующей исходной таблице.

==========

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

Если более важно знать, что было значением поля в любой момент времени (в отличие от записи в целом), то попробуйте более сокращенный подход table-field-value-date. Обратите внимание, что для восстановления всей записи с помощью этого подхода требуется гораздо больше усилий, поэтому забудьте об этом, если когда-нибудь понадобится извлечение всей записи.

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

Answer 4

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

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

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

Использовать базу данных аудита только для целей аудита.

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