Может ли кто-нибудь сказать мне, может ли таблица в реляционной базе данных (например, MySQL/SQL SERVER) без первичного ключа?
Например, я мог бы иметь таблицу day_temperature, где я регистрирую temperature и time. Я не вижу причины иметь первичный ключ для такой таблицы.
Технически вы можете объявить такую таблицу.
Но в вашем случае time следует сделать PRIMARY KEY, так как, вероятно, неправильно иметь разные температуры в одно и то же время и, вероятно, бесполезно иметь одно и то же время.
Логически каждая таблица должна иметь PRIMARY KEY, чтобы вы могли различать две записи.
Если у вас нет ключа-кандидата в ваших данных, просто создайте суррогатную (AUTO_INCREMENT, SERIAL или что-то, что предлагает ваша база данных).
Единственное оправдание отсутствия PRIMARY KEY - это журнал или аналогичная таблица, которая подвержена тяжелым DML и имеет индекс на нем, будет влиять на производительность за пределами уровня допуска.
Как всегда зависит.
Таблица не имеет, чтобы иметь первичный ключ. Гораздо важнее иметь правильные индексы. Механизм базы данных зависит от того, как первичный ключ влияет на индексы (т.е. Создает уникальный индекс для столбца/столбца первичного ключа).
Однако в вашем случае (и на 99% других случаях), я бы добавил новый уникальный индекс автоматического увеличения,, как temp_id, и сделать его суррогатным первичным ключом.
Это упрощает сохранение этой таблицы - например, поиск и удаление записей (т.е. дублированные записи) - и поверьте мне - для каждой таблицы приходит время исправить: (.
Не будет ли первичный ключ естественным временем? у вас когда-нибудь будет более одной температуры в течение определенного времени?
Лучше задать вопрос: "Почему бы вам никогда не сделать таблицу без первичного ключа
Если возможность иметь повторяющиеся записи (например, за одно и то же время) не является проблемой, и вы не ожидаете, что вам придется запрашивать конкретные записи или диапазон записей, вы можете обойтись без какого-либо ключа.
Вам не нужен ПК, но он рекомендовал, чтобы он был у вас. Это лучший способ идентифицировать уникальные строки. Иногда вам не нужен автоматический инкремент int PK, а скорее создайте PK для чего-то другого. Например, в вашем случае, если есть только одна уникальная строка за раз, вы должны создать PK на время. Он ускоряет поиск по времени, плюс гарантирует, что он уникален (вы можете быть уверены, что целостность данных не нарушена):
Я бы включил ключ суррогата/автоинкремент, особенно если есть возможность дублирования времени/температуры. У вас не было бы другого способа однозначно идентифицировать повторяющуюся строку.
Время станет вашим первичным ключом. Это поможет индексировать этот столбец, чтобы вы могли запрашивать данные на основе диапазона дат. PK - это то, что в конечном итоге делает вашу строку уникальной, поэтому в вашем примере datetime является PK.
Я столкнулся с тем же вопросом в одной из таблиц, которые я сделал.
Проблема заключалась в том, что PK должен был состоять из всех строк таблицы, все хорошо, но это означает, что размер таблицы будет расти очень быстро с каждой вставленной строкой.
Я не хочу иметь PK, но имею только индекс в строке, в которой я выполняю поиск.
При репликации базы данных в mysql таблица без первичного ключа может вызвать задержку в репликации.
http://lists.mysql.com/mysql/227217
Наиболее распространенной ошибкой при использовании ROW или MIXED является отказ убедитесь, что каждая таблица, которую вы хотите воспроизвести, имеет ПЕРВИЧНЫЙ КЛЮЧ Это. Это ошибка, потому что когда событие ROW (например, одно задокументировано выше) отправляется рабу и ни главная копия ни рабская копия таблицы не имеет ОСНОВНОГО КЛЮЧА на столе, нет способа легко определить, какую уникальную строку вы хотите репликация для изменения.
В соответствии с вашим ответом я бы рассмотрел три варианта:
эти два варианта лучше всего подходят для скорости поиска, если вы интенсивно читаете, но это приведет к снижению скорости вставки, так как индексы также должны быть обновлены.
Кроме того, очень важно рассмотреть здесь количество элементов и подумать о будущих последствиях использования числа с автоприращением. если вы планируете делать МНОГО вставок, то риск будет заключаться даже в увеличении размера без знака bigint с автоматическим увеличением, поскольку в конечном итоге он закончится. В вашем примере, я думаю, вы будете сохранять данные ежедневно - как долго? это было бы проблематично, если бы вы экономили темп каждую минуту... поэтому я возьму это как крайний пример.
Я думаю, что лучше подумать о том, что вам нужно из таблицы. Вы делаете "сохранить и забыть" в течение всего года для температуры в каждую минуту? Собираетесь ли вы часто использовать эту таблицу в процессе принятия решений в вашей бизнес-логике? Я думаю, что лучше всего отделить данные, необходимые для работы в режиме реального времени (oltp), от данных долгосрочного сохранения, которые потребуются редко, а задержка поиска может быть высокой (olap). даже стоит дублировать данные в две разные таблицы, одна сильно индексируется и время от времени стирается для контроля количества элементов, а вторая фактически сохраняется на магнитном диске практически без индексов (можно перенести схему из вашего основной фс в другой фс).
Даже если вы не добавите первичный ключ в таблицу InnoDB в MySQL, MySQL добавляет в эту таблицу скрытый кластеризованный индекс. Если вы не определили первичный ключ, MySQL находит первый индекс UNIQUE, где все ключевые столбцы имеют значение NOT NULL, а InnoDB использует его в качестве кластеризованного индекса.
Если таблица не имеет первичного ключа или подходящего индекса UNIQUE, InnoDB внутренне генерирует кластерный индекс GEN_CLUST_INDEX для синтетического столбца, содержащего значения идентификатора строки.
https://dev.mysql.com/doc/refman/8.0/en/innodb-index-types.html
У меня есть лучший пример таблицы, для которой не нужен первичный ключ - столярная таблица. Скажем, у меня есть таблица с чем-то, называемая "возможностями", и другая таблица с чем-то, называемым "группами", и я хочу, чтобы таблица столов сообщила мне обо всех возможностях, которые могут иметь все группы, так что это просто
create table capability_group
( capability_id varchar(32),
group_id varchar(32));
Нет причин иметь первичный ключ, потому что вы никогда не обращаетесь к одной строке - вам либо нужны все возможности для данной группы, либо все группы для данной способности. Было бы лучше иметь уникальное ограничение на (capabilty_id, group_id) и отдельные индексы в обоих полях.