Первичный ключ SQL-это необходимо?

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

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

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

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

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

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

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

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

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

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

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

Если нет-это зависит от обстоятельств. И это будут вовсе не нормализованные данные

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