Нужен ли столбец ID в SQL?

Традиционно я всегда использовал столбец идентификатора в SQL (в основном mysql и postgresql).

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

Итак, если каждая строка в таблице SQL уникальна, нужна ли таблица идентификаторов первичного ключа и есть ли переменные производительности ant с или без одного?

Спасибо!

EDIT/Дополнительная информация: Конкретный пример, который заставил меня задать этот вопрос, - это таблица, которую я использую для таблицы "многие-ко-многим-многим" (если мы все еще называем ее той точкой), она имеет 4 столбца (плюс ID) каждый из которых представляет собой идентификатор внешней таблицы, и каждая строка всегда будет числовой и уникальной. только одному из столбцов разрешено быть нулевым.

Я понимаю, что для обычных таблиц столбец первичного ключа ID - ОЧЕНЬ хорошая вещь. Но я чувствую, что на этой конкретной таблице он просто тратит пространство и замедляет добавление новых строк.

Ответ 1

Если у вас действительно есть уже существующий столбец в вашем наборе данных, который уже однозначно идентифицирует вашу строку - тогда нет, нет необходимости в дополнительном столбце идентификатора. Однако первичный ключ должен быть уникальным (в ВСЕ) и не может быть пустым (должен быть NOT NULL).

В моем 20-летнем опыте разработки баз данных, это почти никогда не бывает так. Большинство "естественных" идентификаторов, которые кажутся уникальными, в конечном счете не являются. Номера социального страхования США не гарантируются как уникальные, и большинство других "естественных" ключей становятся почти уникальными - и это недостаточно для системы баз данных.

Итак, если у вас действительно есть правильный, уникальный ключ в ваших данных - используйте его! Но большую часть времени проще и удобнее иметь только один идентификатор суррогата, который вы можете гарантировать, будет уникальным по всем строкам.

Ответ 2

Не путайте логическую модель с реализацией.

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

Великий. Однако...

На практике наличие первичного ключа с несколькими столбцами имеет свои недостатки: оно широко, не очень хорошо при кластеризации и т.д. Там есть много информации и в списке "связанных" вопросов справа

Итак, вы обычно

добавить суррогатный ключ (столбец ID)
добавить уникальное ограничение, чтобы другие уникальные столбцы
столбец идентификатора будет кластеризованным ключом (может быть только один на таблицу)
Теперь вы можете сделать ключом основной ключ

Основное исключение - это ссылки или таблицы "многие-ко-многим", которые связывают 2 столбца ID: суррогат не нужен (если у вас нет ORM Braindead)

Изменить ссылку: Что мне выбрать для моего основного ключа?

Edit2

Для много-много таблиц: SQL: нужен ли вам автоматически-инкрементный первичный ключ для таблиц Many-Many?

Ответ 3

У вас должен быть один столбец в каждой уникальной таблице.

EDITED...

Это одна из основ построения таблицы базы данных. Это идентификатор строки - идентификатор идентифицирует, какие строки действуют (обновлено/удалено и т.д.). Опираясь на комбинации столбцов, которые являются "уникальными", например (first_name, last_name, city), поскольку ваш ключ может быстро привести к проблемам, когда существуют два Джона Смита, или, что еще хуже, когда Джон Смит перемещает город, и вы получаете столкновение.

В большинстве случаев лучше всего использовать искусственный ключ, который гарантированно будет уникальным - как целое число с автоматическим добавлением. Вот почему они так популярны - они нужны. Обычно ключевой столбец просто называется id, а иногда <tablename>_id. (Я предпочитаю id)

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

В идеале у вас должен быть только один уникальный столбец. То есть должен быть только один ключ.

Ответ 4

Использование идентификаторов к ключевым таблицам означает, что вы можете изменять контент по мере необходимости, не перепутывая вещи

Ex. если каждая строка указывает на уникального пользователя, что произойдет, если он/она изменит свое имя, чтобы сказать, что Джон Блблббе, который уже был в дБ? И опять же, что произойдет, если вы захотите узнать подробности Джона Блблббе, чьи данные будут подхвачены? старый Джон или один хо изменили его имя? Ну, если ответ на вопросы бота - "ничего особенного не произойдет", тогда, да, вам действительно не нужен столбец "ID":]

Важно:

Кроме того, наличие столбца числового идентификатора с номерами намного быстрее, когда вы ищете точную строку, даже если таблица не имеет никаких указательных клавиш или имеет более одного уникального

Ответ 5

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

Однако в целом это будет намного медленнее, потому что построение первичного индекса будет намного дороже. Основной индекс используется системами управления реляционными базами данных (РСУБД) не только для определения уникальности, но и для того, как они упорядочивают и структурируют записи на диске.

Простой первичный ключ одного возрастающего значения, как правило, является наиболее эффективным и самым простым решением для RDBMS.

Ответ 6

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

Ответ 7

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

Ответ 8

Идентификатор может быть более значимым, например, идентификатор сотрудника может представлять, из какого он отдела, год его вступления и так далее. Кроме того, СУБД поддерживает множество операций с идентификаторами.