TRUE или FALSE: Хороший дизайн призывает, чтобы каждая таблица имела первичный ключ, если ничто иное, рабочее целое число
Рассмотрите сценарий продуктового магазина (я составляю это), где у Вас есть записи ФАКТА, которые представляют транзакцию продаж, где столбцы Таблицы фактов включают
SaleItemFact Table
------------------
CustomerID
ProductID
Price
DistributorID
DateOfSale
Etc
Etc
Etc
Даже если существуют дубликаты в таблице, когда Вы рассматриваете ВСЕ ключи, я утвердил бы, что суррогат, выполняющий числовой ключ (т.е. столбец идентификационных данных), должен быть составлен, например, TransactionNumber Целого числа типа.
Я вижу, что кто-то утверждает, что Таблица фактов не могла бы иметь уникального ключа (хотя я изобрету один и потрачу впустую 4 байта, но как насчет таблицы измерений?
5 ответов
Первая нормальная форма требует наличия первичного ключа для каждой таблицы. Так что это минимум, необходимый для хорошего проектирования базы данных. То, что вы выбираете в качестве первичного ключа, вызывает много споров. Но первой нормальной формы для проектирования баз данных нет.
Для хранилищ данных таблицы фактов часто имеют составной первичный ключ, обычно составной из всех внешних ключей ваших таблиц измерений.
Довольно часто в ваших таблицах фактов нет никакого первичного ключа, так как они часто не служат никакой цели, кроме траты места - а для больших хранилищ данных пространство может быть довольно большим. Однако ваши таблицы измерений будут иметь первичные ключи.
Если вы говорите об OLTP-части вашего продуктового магазина, вы обычно следуете стандартному дизайну базы данных OLTP, нормализуете свои таблицы и предоставляете первичный ключ.
Одна из многих причин иметь уникальный ключ для каждой строки (созданный на основе данных или иным образом) - это облегчить обновление или удаление этой конкретной строки. .
В любом случае, этот вопрос довольно глупый, потому что на кону нет инженерного компромисса. Отсутствие ключа не дает никаких реальных преимуществ, так в чем же смысл? Верно / да, строки должны иметь уникальные идентификаторы.
Верно. Подумайте концептуально: все уникально, даже если это не определяется уникальными данными. Таким образом, если вы вводите данные в таблицу, и они содержат точно такую же информацию, они по-прежнему уникальны, поскольку были введены дважды.
Оставив это, вы получаете возможность легко выбирать, обновлять, удалять на основе идентификатора по относительно низкой цене (4 байта). Возможно, чем больше таблица, тем полезнее идентификатор. Таким образом, 4 байта становятся все меньше и меньше точки, чем больше таблица: -)
Поскольку ваш вопрос находится в разделе datawarehousing:
Таблицы измерений должны иметь суррогатный (бессмысленный) первичный ключ, обычно автоинкрементное целое число; и бизнес-ключ, который однозначно идентифицирует объект, который описывает строка таблицы - например, адрес электронной почты, полное имя или что-то подобное.
Таблицы фактов в основном (почти всегда) имеют первичный ключ, который является комбинацией двух или более внешних ключей.
В таблицах фактов не должно быть дубликатов при объединении внешних ключей в первичный ключ. Чтобы проверить это, просто попробуйте загрузить одну и ту же транзакцию дважды - она должна завершиться неудачей. Автогенерируемый первичный ключ не предотвратит этого, поскольку он не существует за пределами хранилища. Обычно проблема решается включением временной метки в первичный ключ.
Иногда таблица фактов используется как измерение или в представлении, которое может действовать как измерение. В этом случае удобно иметь одно (большое) целое число в качестве первичного ключа, вместо нескольких полей FK - однако, исходная комбинация FK и временной(ых) метки(ок) все равно должна однозначно идентифицировать строку факта.