SQL Primary Key - это необходимо?

У меня есть список предметов. Большинство из этих предметов не будет на складе. Таблица элементов имеет идентификатор, имя, описание. Количество элементов хранится в другой таблице с именем инвентарь. В таблице инвентаря есть item_id и количество предметов, находящихся на складе.SQL Primary Key - это необходимо?

Нужен ли мне первичный ключ для таблицы инвентаря? Если да, следует ли использовать последовательный или составной ключ? Когда все нормально, чтобы таблица не имела первичного ключа?

Редактировать: Спасибо всем за то, что вы очень информативны. Теперь у меня всегда будут первичные ключи, за исключением редких исключений. Я также узнал немного больше о последовательных или составных ключах.

источник

2012-01-08 deadghost

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

@mark_s Нет никакой связи с вопросом, но у меня есть личное мнение, что в очень ОСОБЫХ случаях я могу иметь и использовать кучи лучше, чем таблицы на основе PK. 8). Позволяет перейти в чат? –

@mark_s Да, точно, только загруженные груды правила кучи 8-) –

Всегда старайтесь иметь первичный ключ.

Если вы не уверены, у вас есть первичный ключ.

Даже если вы 99,99% уверены, что вам это не понадобится, имейте это. Требования меняются, как я узнал на протяжении многих лет.

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

Там какая-то более большая информация об этом здесь:
http://weblogs.sqlteam.com/jeffs/archive/2007/08/23/composite_primary_keys.aspx

и здесь:
http://www.techrepublic.com/article/the-great-primary-key-debate/1045050
здесь:
http://databases.aspfaq.com/database/what-should-i-choose-for-my-primary-key.html
и здесь:
Should I use composite primary keys or not?

В вашем примере, я безусловно, есть.

Решение «не иметь» должно быть основано на очень четкой необходимости и понимании, а также фактических или прогнозируемых (например, томах) проблемах с их использованием.

Огромный пример этой потребности возникает при отладке и устранении неполадок. Подобно тому, как создавать и обновлять столбцы в каждой таблице (еще один мой любимый), эта информация не может первоначально использоваться/для передней части, но мальчик может быть полезен при отслеживании и разрешении проблем. (Кстати обновление марки часто в настоящее время стандарта в рамках как Ruby On Rails, который также хорошо работает с конвенцией каждой таблицы, имеющей id поля!)

источник

2012-01-08 12:39:39

'Единственные примеры, о которых я действительно могу думать, это таблицы многих-ко-многим с двумя иностранными ключами - почему бы не сделать два внешних ключа в составных первичных ключах? – gldraphael

Если у вас есть только одна строка инвентаризации за единицу - то это будет намного дешевле (средняя - CPU и IO), что он будет находиться в той же таблице Item,

, если нет - это зависит от многого. И это не будет нормированные данные на всех

Но, насколько я понимаю, этот вопрос, и если вы настаивают на двух столах - да, лучше, чтобы иметь индекс ITEM_ID поле

источник

2012-01-08 12:37:39

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

У двух таблиц есть причина, только если у вас есть что-то вроде доставки каждого предмета с его отдельной ценой, иначе вы можете легко объединить их вместе. –

Хм хорошо. Я объединю их вместе. Я пришел к выводу, что количество попадает в объект объекта. Мое рассуждение состоит в том, что таблица элементов описывает элемент в каждой строке, и это количество все еще описывает элемент. Возможно, я переименую таблицу в «Элементы», поскольку каждая строка описывает элементы больше, чем один элемент ... или нет, поскольку 1 элемент довольно глупо. – deadghost

В общем : Каждая таблица должна иметь ПК. По крайней мере, каждая таблица должна иметь некоторый индекс CLUSTER. PK не должен быть одним специальным столбцом, но наличие строк без уникальной идентификации в системе (РСУБД) не является хорошей практикой.

Может быть несколько случаев, когда PK не требуется, но это исключения из правила.

источник

2012-01-08 12:38:17 TcKs

Кластеризованный индекс - это физическая деталь реализации индекса, который совершенно не имеет отношения к вопросу о необходимости ПК или нет. И к тому же: не каждая СУБД * имеет * кластерные индексы –

a_horse_with_no_name: Если СУБД не имеет пользовательских индексов кластера, то СУБД имеет собственный внутренний способ, как объединить данные. Конечно, если ваша СУБД в этом случае, проигнорируйте мою заметку о CLUSTER для этой СУБД :). – TcKs

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

РЕДАКТИРОВАТЬ: Как отмечали другие, как правило, если у вас нет веских оснований для первичного ключа, вам будет хорошо смотреть на структуру таблицы, чтобы увидеть, можете ли вы объединить ее с другой таблицей, в этом Вероятно, таблица элементов. Я вижу случаи, когда это не вариант (например, вы не можете изменить схему, просто добавьте новые таблицы), но это стоит посмотреть.

источник

2012-01-08 12:38:43

ли нужен первичный ключ для таблицы инвентаризации?

Можно ли считать данные реляционными? По определению отношение не имеет дубликатов кортежей. SQL позволяет дублировать строки в таблице. Поэтому, чтобы гарантировать отсутствие повторяющихся строк на практике, каждая таблица должна иметь как минимум одно уникальное ограничение. Короче говоря, у вас есть хорошая причина не помещать уникальное ограничение на каждый ключ кандидата в таблице. По определению, нулевой или один ключ-кандидат может быть обозначен как «первичный», а какой (если он есть) должен получить это обозначение, является произвольным.

Должен ли я использовать последовательный или составной ключ?

Я думаю, что это опечатка. Одностолбцовый ключ известен как «простой ключ», а не «серийный ключ». Из вашего описания в таблице инвентаря есть единственный кандидат на ключ от item_ID which is a simple key. Единственный возможный составной ключ - это суперключ и, если только он не должен ссылаться на внешний ключ, не следует ограничивать с помощью уникального ограничения.

Когда все в порядке, чтобы таблица не имела первичного ключа?

Когда все ключи-кандидаты были ограничены с использованием ограничений UNIQUE или когда таблица не предназначена для хранения реляционных данных.

источник

2012-01-09 15:06:02 onedaywhen

SQL Primary Key - это необходимо?

ответ

Смежные вопросы