Блог

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

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

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

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

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

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

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