таблица аудита против медленно меняющегося измерения типа 2

В SQL Server 2008+ мы хотели бы включить отслеживание исторических изменений в таблице «Клиенты» в рабочей базе данных.

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

Количество строк будет меньше 100 000, а количество изменений на запись будет составлять в среднем 1,5 в год.

Есть как минимум два способа моделирования этого:

  1. В виде таблицы медленно изменяющегося измерения типа 2 называется CustomersHistory со столбцами для EffectiveStartDate, EffectiveEndDate (установлено значение NULL для текущей версии клиента) и столбцами аудита, такими как ChangeReason и ChangedByUsername. Затем мы создадим представление Customers для этой таблицы, которая отфильтрована до EffectiveEndDate=NULL. Большинство частей нашего приложения будут запрашивать с использованием этого представления, и только части, которые должны учитывать историю, будут запрашивать базовую таблицу. Для повышения производительности мы могли бы материализовать представление и/или добавить отфильтрованный индекс для EffectiveEndDate=NULL.

  2. С отдельной таблицей аудита. Каждое изменение записи Customer записывается один раз в таблицу Customer и еще раз в таблицу аудита CustomerHistory.

Судя по быстрому обзору вопросов StackOverflow, № 2 кажется гораздо более популярным. Но связано ли это с тем, что большинству приложений БД приходится иметь дело с устаревшими и мошенническими авторами?

Учитывая, что мы начинаем с чистого листа, каковы плюсы и минусы того или иного подхода? Что бы вы порекомендовали?


sql sql-server-2008 dimensional-modeling data-modeling scd
person Justin Grant    schedule 20.06.2014    source источник
comment
Это база данных OLTP, а не отдельное хранилище данных, но рассматриваемая таблица меняется не очень часто.   -  person Justin Grant    schedule 23.06.2014
comment
Я предполагаю, что обычной операцией в приложении будет отображение списка транзакций данного клиента. SCD 2 каждый раз будет требовать дополнительного соединения - CustomersCurrentView WHERE Customer = 'John Doe' JOIN CustomersHistory JOIN Transactions. Мое предложение: если исторические данные используются нечасто, храните их в наборе отдельной таблицы аудита; используйте SCD 2 только в том случае, если компоненты, учитывающие историю, составляют важную часть приложения. +1 за очень интересный вопрос!   -  person Marek Grzenkowicz    schedule 24.06.2014

Ответы (1)


arrow_upward
2
arrow_downward

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

Теперь я понимаю, что вы создадите отдельное материализованное представление с EffectiveEndDate = NULL, и оно будет использоваться в большинстве ваших объединений. Кроме того, для вас объем данных сравнительно невелик (100 000). При средних изменениях всего 1,5 в год я не думаю, что объем данных / производительность запросов и т. д. станут вашей проблемой в ближайшем будущем.

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

person hashbrown    schedule 28.06.2014