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

Question

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

Пожалуйста, дайте мне знать, если вам нужна дополнительная информация.

Answer 1

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

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

Столбец «Источник» помогает в родословной.

Итак, предположим, что у вас есть три системы источников с различными форматами «Код продукта», которые являются всеми символами 8, 10 и 15 соответственно. Добавить столбцы:

SourceID CHAR(5) - e.g. or a further surrogate look-up to a 'Source' table. 
ProductCode CHAR(15) 

15 = MAX (8,10,15).

Или даже VCHAR(20) в зависимости от того, можете ли вы ожидать будущего приобретения источников. 20 Символы довольно велики для любого идентификатора источника. Но рассмотрите практику в соответствующей проблемной области.

Никогда

SourceID CHAR(5) 
ProductCode1 CHAR(8) 
ProductCode2 CHAR(10) 
ProductCode3 CHAR(15) 

Если только потому, что если источник 4 показывает вверх вы добавляете столбцы. Также потому, что отчет не будет полезен. Сложно будет присоединиться к общим «общим» таблицам, с которыми вам придется иметь дело. Вы можете найти индексы хранения и раздувания отходов с потерянным пространством производительности, выбрав VCHAR.