Требуется ли первичный ключ в этом конкретном сценарии?

Question

У меня есть таблица имен с (id, имя, отчество, фамилия, пол) и таблица электронной почты с (id_fk, email_add)

Infact У меня будут похожие таблицы второго типа, например телефонная таблица (id_fk, phone_no), где id_fk - это внешний ключ, ссылающийся на идентификатор в таблице имен.

Требуется или, скорее, есть веская причина иметь первичный ключ во второй и третьей таблицах? Или другие подобные таблицы? Или вы бы предложили другую схему?

PS: таблицы предназначены для приложения для хранения контактов

Answer 1

В описываемых вами случаях первичным ключом является вся таблица (id_fk, phone_no), так как строки не являются совместно используемыми, представляют неупорядоченную коллекцию и имеют только значение, а не какой-либо собственный идентификатор.

Answer 2

Моя философия дизайна заключается в том, что каждая таблица всегда имеет один столбец int identity pk.

Как представляется, это неоднозначное решение, как показали предыдущие комментарии к SO, но это также очень удобно.

Answer 3

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

Также неплохо было бы взглянуть на другую схему именования для ваших внешних ключей, «id_fk» может быть немного запутанным, так как не указывает на то, к какому «идентификатору» таблицы он относится, что-то вроде «name_id». "может быть лучшим выбором.

Answer 4

У вас обязательно должен быть первичный ключ для всех ваших таблиц. В случае (id_fk, phone_no) вы можете использовать составной ключ, состоящий из обоих столбцов, или добавить другой столбец в качестве первичного ключа. Я бы порекомендовал последнее, так как это в конечном итоге уменьшит сложность всего и будет намного более удобным, если вы используете ORM.

Answer 5

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

Лично я предпочитаю использовать строго технические первичные ключи, обычно это столбец с автоматическим номером. Одним из преимуществ является упрощение обновления и удаления записей с использованием идентификатора, а не запоминание старого значения в формах HTML и т. Д.

Answer 6

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

Лично я бы также рекомендовал использовать для вашего первичного ключа столбец, не зависящий от данных, например, guid / uuid / serial. Используя поле, которое не содержит пригодных для использования данных, вы никогда не окажетесь в ситуации, когда вам придется обновлять первичный ключ, что может стать еще одной беспорядочной операцией после роста вашей базы данных.

Answer 7

Существует первичный ключ для телефонного стола. Каждая пара (id_fk, phone_no) однозначно определяет каждую запись, поэтому в данном случае первичный ключ является составным.

http://weblogs.sqlteam.com/jeffs/archive/2007/08/23/composite_primary_keys.aspx

Answer 8

Зачем вам нужны отдельные таблицы для адресов электронной почты и телефонных номеров? Хранить их все в одной таблице гораздо эффективнее. Ваша схема может выглядеть так:

(псевдо SQL)

Create table ContactName (
       CONTACT_ID integer not null default auto_increment,
       etc
       )

CREATE TABLE TELECOM_CLASSES (
    CLASS_ID INTEGER NOT NULL DEFAULT AUTO_INCREMENT,
    CLASS_NAME VARCHAR(200) NOT NULL 
              CHECK (CLASS_NAME  IN ('email','tel','fax',etc)),
    etc
     );

CREATE TABLE CONTACT_TELECOMS (
    TELECOM_ID INTEGER NOT NULL DEFAULT AUTO_INCREMENT,
    CONTACT_ID INTEGER NOT NULL REFERENCES CONTACTNAME (CONTACT_ID),
    CLASS_ID INTEGER NOT NULL REFERENCES TELECOMS_CLASSES (CLASS_ID),
    TELECOM VARCHAR(200) NOT NULL,
    etc

);