Верно или неверно: хороший дизайн требует, чтобы у каждой таблицы был первичный ключ, если не что-нибудь еще, работающее целое число

Question

Рассмотрим сценарий продуктового магазина (я это придумываю), где у вас есть записи FACT, представляющие транзакцию продажи, где столбцы таблицы Fact включают

SaleItemFact Table
------------------
CustomerID  
ProductID  
Price  
DistributorID  
DateOfSale  
Etc  
Etc  
Etc  

Даже если в таблице есть дубликаты, когда вы рассматриваете ВСЕ ключи, я бы сказал, что должен быть создан суррогатный работающий цифровой ключ (то есть столбец идентификаторов), например, TransactionNumber типа Integer.

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

Answer 1

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

Answer 2

Поскольку ваш вопрос находится под хранилищем данных :

• Таблицы измерений должны иметь суррогатный (бессмысленный) первичный ключ, обычно с автоматическим приращением;и бизнес-ключ, который однозначно идентифицирует объект, который описывает строка таблицы - например, адрес электронной почты, полное имя или подобное.

• Таблицы фактов, в основном (почти всегда), имеют первичный ключ, которыйявляется комбинацией двух или более внешних ключей.

В таблицах фактов не должно быть дубликатов при объединении внешних ключей в первичный ключ.Чтобы проверить это, просто попробуйте загрузить одну и ту же транзакцию дважды - она ​​не удастся.Автоматически сгенерированный первичный ключ не помешает этому, потому что он не существует вне склада.Эту проблему обычно можно решить, включив отметку времени в первичный ключ.

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

Answer 3

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

В любом случае, этот вопрос довольно глупый, потому что на самом деле на кону нет инженерного компромисса. Нет реальной предполагаемой выгоды от отсутствия ключа, так какой в ​​этом смысл? Правда / да, строки должны иметь уникальные идентификаторы.

Answer 4

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

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

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

Answer 5

True.Думайте концептуально, все уникально, даже если оно не определено уникальными данными.Поэтому, если вы вводите данные в таблицу, и они имеют точно такую ​​же информацию, они все еще уникальны, так как они были введены дважды.

Оставляя это, вы получаете возможность легко выбирать, обновлять, удалять напо идентификатору при относительно низкой стоимости (4 байта).Что, вероятно, чем больше таблица, тем более полезен идентификатор.Таким образом, 4 байта становятся все меньше и меньше, чем больше таблица: -)