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

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

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

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

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


data-warehouse database-design
person Chad    schedule 06.03.2010    source источник
comment
Таблицы аудита того, что произошло, не требуют первичных ключей. Добавление индекса (который имеет некоторый уровень сериализации и накладных расходов), который может вызывать только сбои и не добавляет никакого другого значения, является противоположностью хорошему дизайну.   -  person Adam Musch    schedule 06.03.2010
comment
Различные производители могут иметь более сильное мнение по этому вопросу. На какой из них вы ориентируетесь?   -  person Rick James    schedule 30.12.2018

Ответы (5)


arrow_upward
11
arrow_downward

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

person Randy Minder    schedule 06.03.2010
comment
Первая нормальная форма для неженок. :) Я все равно буду за вас, потому что это довольно хороший ответ - person Mike Sherov; 06.03.2010

arrow_upward
3
arrow_downward

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

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

person wsorenson    schedule 06.03.2010
comment
В Oracle все так и есть; это псевдоколонка ROWID. - person Adam Musch; 06.03.2010

arrow_upward
3
arrow_downward

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

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

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

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

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

person Damir Sudarevic    schedule 06.03.2010
comment
Если размер соответствует country, я бы посоветовал использовать стандартные двухбуквенные коды лучше, чем целые числа с автоматическим приращением: UK, FR, DE, US, RU, `CZ '. И объявить его ascii - person Rick James; 30.12.2018
comment
Добавление метки времени опасно - однажды вы выполните два действия за одну секунду. Или летнее время превратит целый час в одну секунду. - person Rick James; 30.12.2018

arrow_upward
2
arrow_downward

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

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

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

person nos    schedule 06.03.2010

arrow_upward
-1
arrow_downward

Истинный. Подумайте концептуально: все уникально, даже если не определяется уникальными данными. Таким образом, если вы вводите данные в таблицу, и они содержат точно такую ​​же информацию, они по-прежнему уникальны, поскольку были введены дважды.

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

person Seaux    schedule 06.03.2010
comment
-1: не все уникально. См. stackoverflow.com/questions/2390854/. - person John Saunders; 06.03.2010