Таблица базы данных может быть без первичного ключа?

У меня есть лучший пример таблицы, для которой не нужен первичный ключ - таблица объединения. Скажем, у меня есть таблица с чем-то, называемым «возможностями», и другая таблица с чем-то, называемым «группами», и мне нужна объединенная таблица, которая сообщает мне все возможности, которые могут иметь все группы, так что в основном это

create table capability_group
(  capability_id varchar(32),
    group_id     varchar(32));

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

Разве не самое время использовать первичный ключ? Будет ли у вас когда-либо иметь более одной температуры в данное время?

Лучше задать вопрос: «Зачем вам вообще создавать таблицу без первичного ключа»

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

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

Технически можно объявить такую таблицу.

Но в вашем случае time следует сделать ПЕРВИЧНЫМ КЛЮЧОМ, так как, вероятно, неправильно иметь разные температуры для одного и того же времени и, вероятно, бесполезно иметь одно и то же более одного раза.

По логике, каждая таблица должна иметь PRIMARY KEY, чтобы можно было различать две записи.

Если у вас нет ключа-кандидата в ваших данных, просто создайте суррогатный (AUTO_INCREMENT, SERIAL или что-то еще, что предлагает ваша база данных).

Единственным оправданием отсутствия PRIMARY KEY является журнал или аналогичная таблица, которая подвержена тяжелому DML, и наличие индекса на нем повлияет на производительность за пределами уровня допуска.

Как всегда это зависит .

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

Однако в вашем случае (и в 99% других случаях тоже) я бы добавил новый уникальный столбец с автоматическим приращением , например temp_id , и сделал бы его суррогатным первичным ключом.

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

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

Я бы включил суррогатный/автоинкрементный ключ, особенно если есть вероятность дублирования показаний времени/температуры. У вас не будет другого способа однозначно идентифицировать дублирующую строку.