Необходим первичный ключ в таблицах фактов

Question

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

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

Answer 1

Мне нравится помещать столбцы идентификаторов во все таблицы. Это упрощает идентификацию определенных c строк для обновления и удаления.

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

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

Answer 2

Всегда хорошо использовать go для ключа кластеризации, что позволяет легко искать данные, когда они нам нужны. Ключ кластеризации используется не только для запросов кластеризованного индекса. Он также сохраняется на каждой конечной странице некластеризованного индекса для возврата к страницам данных при поиске по ключу.

Характеристики хорошего ключа кластеризации:

• уникальный (нет необходимости добавлять uniquefier, чтобы сделать значение уникальным)
• инкремент (уменьшает фрагментацию)
• узкий (меньшее количество байтов для хранения в древовидных страницах кластерного индекса & на конечных страницах некластеризованного индекса)
• Stati c (уменьшает фрагментацию)
• не допускает значения NULL (избегает нулевых блоков)
• фиксированная ширина (избегает переменной блоков)

Подробнее в сообщении Kimberly Tripp о ключе кластеризации

Идентификационные данные удовлетворяют всем этим пунктам. Они хорошие кандидаты для кластерного индекса. Если вы собираетесь хранить данные дольше, вы можете go для Bigint, а если вы собираетесь хранить данные в течение одного года и очистить, вы можете go для int самого типа данных.