Наша команда планирует добавить отсутствующие ключи измерений (FK) в наши таблицы фактов, чтобы обеспечить прямой запрос между нашими измерениями и таблицами фактов, а не просматривать таблицы. По сути, больше склоняюсь к звездной схеме. Это улучшит производительность запросов (поскольку потребуется меньше объединений).
Я читал в Интернете, что ограничения внешнего ключа (FK) будут влиять на производительность вставки, обновления и удаления.
Есть ли другие вещи, которые мы должны рассмотреть?
Основным недостатком является увеличение размера записей таблицы фактов. Вы не указываете размеры строк, но добавление новых внешних ключей может значительно повлиять на размер строки.
В большинстве баз данных увеличение размера строки в таблице фактов замедлит выполнение запросов. Однако в столбцовой базе данных это не будет проблемой.
На самом деле увеличение размера может перевесить преимущества отказа от объединений.
В общем, я бы не беспокоился о соединениях в таблицах измерений малого и среднего размера, которые относятся к первичному ключу. То есть сделать много тестов на полномасштабных данных, прежде чем вносить такие радикальные изменения.
Влияние на inserts заключается просто в том, что ключи должны быть проверены. Однако это проверка первичных ключей справочных таблиц, поэтому эти проверки выполняются довольно быстро. Больше явно дороже, чем меньше, но накладные расходы, вероятно, не станут решающим фактором.
Одна вещь, которая может быть преимуществом или недостатком, заключается в том, что размеры являются статическими во время ввода. Обновление таблицы фактов, как правило, довольно дорого. Однако размеры меняются. Например, время от времени создаются новые страны. Как это отражено в исторических данных?
В схеме снежинки ваш самый низкий уровень географии (вероятно) будет более точным, чем страна, и необходимо обновить только размеры. И если в таблице фактов необходимо обновить самый нижний уровень, это повлияет на относительно небольшое количество строк.
