MySQL не первичный внешний ключ - PullRequest
Новая
       19

MySQL не первичный внешний ключ

4 голосов
/ 14 ноября 2011

Я немного новичок, и я не могу понять первичные ключи как внешние ключи. Для меня внешние ключи предназначены для соединения двух строк таблицы вместе. Следовательно, логично было бы использовать, например, username таблицы user в качестве внешнего ключа в таблице picture. Это означает, что изображение в этом ряду принадлежит указанному пользователю. Однако, как представляется, общая практика предпочитает использовать бессмысленные числа в качестве первичных идентификаторов. Кроме того, внешний ключ должен / должен ссылаться на первичный ключ. Что если я не знаю первичный ключ, но знаю другой уникальный столбец, в данном случае username, как бы я мог получить первичный ключ из другого оператора MySQL или, в качестве альтернативы, указать внешний ключ для неосновного ключ

Ответы [ 3 ]

8 голосов
/ 14 ноября 2011

Кроме того, внешний ключ должен / должен ссылаться на первичный ключ. Что если я не знаю первичный ключ, но я знаю другой уникальный столбец, в данном случае имя пользователя, как мне получить первичный ключ из другого оператора MySQL или, альтернативно, указать, что внешний ключ указывает на не первичный ключ?

Да, если у вас есть другой уникальный ключ, вы можете использовать внешние ключи, ссылающиеся на него: 

CREATE TABLE user
( userid INT NOT NULL 
, username VARCHAR(20) NOT NULL
---  other fields
, PRIMARY KEY (userid)
, UNIQUE KEY (username)
) ENGINE = InnoDB ;

CREATE TABLE picture
( pictureid INT NOT NULL 
, username VARCHAR(20) 
---  other fields
, PRIMARY KEY (pictureid)
, FOREIGN KEY (username)
    REFERENCES user(username)
) ENGINE = InnoDB ;

И если все внешние ключи в других таблицах ссылаются на этот уникальный ключ (username), бессмысленно иметь бессмысленный идентификатор. Вы можете бросить его и сделать username PRIMARY KEY таблицы.

(Edit :) Есть несколько точек, имеющих автоинкрементный первичный ключ для таблиц InnoDB, даже если он не используется в качестве ссылки, поскольку первый первичный или уникальный индекс по умолчанию сделан индексом кластеризации таблицы. Основное поле char может иметь недостатки производительности для операторов INSERT и UPDATE, но лучше работать в запросах SELECT.

Для обсуждения относительно того, что использовать, суррогатные (бессмысленные, автоматически генерируемые) или естественные ключи и различные взгляды на предмет, прочитайте это: surrogate-vs-natural-business-keys

5 голосов
/ 14 ноября 2011

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

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

1 голос
/ 14 ноября 2011

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

Попробуйте выполнить 

CREATE INDEX user_username_idx ON user(username);

и тогда создание вашего внешнего ключа должно сработать.

...