Первичный ключ SQL - это нужно?

Question

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

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

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

Answer 1

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

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

Даже если вы на 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
и здесь:
Должен ли я использовать составные первичные ключи или нет?

ВВаш пример, у меня определенно был бы один.

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

Если у вас есть только одна строка инвентаря на предмет - тогда будет намного дешевле (в среднем - процессор и ввод-вывод), что он будет в одной и той же таблице предметов,

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

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