Зачем использовать порядковый номер для номера версии в таблице измерений при моделировании хранилища данных

Question

В контексте моделирования измерений, как это обычно бывает, полезно иметь суррогатный ключ в таблице измерений, чтобы отслеживать изменение строк ( http://www.kimballgroup.com/2006/07/design-tip-81-fact-table-surrogate-key/).

Существует три распространенных способа реализации суррогатного ключа 1) порядковый номер 2) номер версии 3) хеш-ключ (используется хранилищем данных)

Мой вопрос: почему порядковый номер предпочтителен в большинстве моделей измерения, которые я видел.

большое спасибо

Answer 1

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

Порядковый номер

Pros

• Порядковые номера просты. Они настолько смехотворно просты, что для большинства целей это пустая трата времени, учитывая все остальное. Не позволяйте никому говорить вам, что это не причина, по которой мы его используем.
• Порядковые номера гарантированы уникальными.
• Порядковые номера настолько малы (узки), насколько это возможно.
• Порядковые номера не кодируют какую-либо информацию, поэтому не имеет значения, измените ли вы содержимое или даже размерность измерения, если факты об этом известны. Это важно, потому что размерность измерений может легко измениться, и поэтому вам не следует использовать суррогатный ключ со значимыми данными (это своего рода точка суррогатного ключа, по крайней мере в Кимбалл-иан-DW)

Cons

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

Номер версии

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

Pros

• Вы получаете доступ к номеру версии данных
• Это может быть способ уникальной идентификации естественного ключа, чтобы вы могли использовать его в качестве ключа измерения DW

Cons

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

гашиш

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

Pros

• Отлично подходит для медленно меняющихся размеров типа 2 - вам не нужно хранить хеш в отдельном столбце, поэтому он экономит место

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

  Cons

• Если вы используете медленно изменяющиеся размеры типа 1, вы просто наносите удар себе в ногу. Обновлен атрибут? Попробуйте обновить первичный ключ, не удаляя половину базы данных, и посмотрите, как далеко вы продвинулись.

• Оно большое. Это делает ваши таблицы фактов большими, и это делает вашу базу данных большой. Если вы используете сжатие на основе столбцов, это, по иронии судьбы, становится более серьезной проблемой, чем больше размерность (до точки...)

Заключение

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