Хранилище данных Snowflake - Генерация идентификатора измерения с буквенно-цифровым символом вместо целого

Question

Является ли хорошей идеей генерировать идентификатор измерения с комбинацией буквенно-цифровых символов вместо целого числа в хранилище данных Snowflake?(https://www.snowflake.com/) Например: допустим, мне нужно построить таблицу измерений из исходной таблицы с тремя комбинациями клавиш. Обычно мы создаем инкрементный суррогатный ключ целочисленного столбца в качестве идентификатора измерения. Вместо этого лучше создать строковый столбецkey1_key2_key3 (сцепленные исходные ключи) как суррогатный ключ для генерации идентификатора измерения? Поскольку снежинки являются распределенной базой данных и работают хорошо, я чувствую, что это должно быть хорошо. Я пытаюсь увидеть любое непредвиденное влияние?

Answer 1

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

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

Answer 2

Я бы создал dimension id как целое число и добавил бы еще один столбец как surrogate key. Таким образом, вы будете следовать стандартам и иметь целочисленный ключ, как и все другие таблицы измерений. Если вы считаете, что суррогатный ключ будет иметь смысл и будет использоваться в объединениях / фильтрах, не стесняйтесь добавлять его.

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

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

https://www.kimballgroup.com/1998/05/surrogate-keys/