Сообщение об ошибке 8110 в SQL 2008
Я построил базу данных и создал следующие таблицы:
Создать таблицу регистрации (
Имя пользователя VARCHAR(30) NOT NULL PRIMARY KEY,
Email VARCHAR(30) NOT NULL PRIMARY KEY,
пароль VARCHAR(50),
)
Создать таблицу Sigin (
Имя пользователя VARCHAR(30) внешний ключ (имя пользователя) ссылки Регистрация (имя пользователя),
пароль VARCHAR(50) внешний ключ (пароль) ссылки Регистрация (пароль)
)
ЭРРО ЭТО:
Msg 8110, Уровень 16, Состояние 0, Строка 1
Невозможно добавить несколько ограничений первичного ключа в таблицу "Регистрация".
Затем я решил одну из них следующим образом:
Создать таблицу регистрации (
Имя пользователя VARCHAR(30) NOT NULL,
Электронная почта VARCHAR(30),
пароль VARCHAR(50),
Ограничение [PK_DNC] первичный ключ КЛАСТЕРИЗОВАН ( имя пользователя, пароль )
)
Создать таблицу Sigin (
Имя пользователя VARCHAR(30) внешний ключ (имя пользователя) ссылки Регистрация (имя пользователя),
пароль VARCHAR(50) внешний ключ (пароль) ссылки Регистрация (пароль)
)
Но теперь сообщение об ошибке:
Msg 1776, Уровень 16, Состояние 0, Строка 1
В ссылочной таблице "Регистрация" нет первичных или потенциальных ключей, соответствующих списку ссылочных столбцов во внешнем ключе "FK__Sigin__UserName__1ED998B2".
Msg 1750, Уровень 16, Состояние 0, Строка 1
Не удалось создать ограничение. См. предыдущие ошибки.
Что я уже пробовал:
Как справиться с этой проблемой,пожалуйста, помогите мне.
phil.o
Использование текстовых полей в качестве первичных ключей-действительно плохая идея с точки зрения производительности, не говоря уже о составном ключе.
Используйте целочисленный тип в качестве первичного ключа, который будет использоваться в качестве ссылки для связанных таблиц.
Более того, делать уникальным сочетание имени пользователя и электронной почты-это ошибка: имя пользователя должно быть уникальным, а электронная почта должна быть уникальной, и то и другое отдельно.
Stack Holder
какое-нибудь решение этого вопроса от вас?
0x01AA
После 30 лет работы с sql я все еще не уверен, что это правильный путь.
"Использование текстовых полей в качестве первичных ключей-действительно плохая идея":
Я согласен и не согласен. Я делаю это с 30 лет, используя целочисленный тип в качестве "внутреннего ключа" для управления отношениями. Но как насчет того, что это означает, что обычно вам нужно поддерживать также что-то вроде User_ID, который является "основным пользователем"? Это означает, что на один лишний индекс больше... все равно после 30 лет у меня есть "шизофренический" взгляд на это.
С точки зрения теории User_ID должен быть первичным. Но часто теория и практика отличаются.
Только комментарий с моей стороны, не принимайте его слишком серьезно
Бруно
phil.o
Это очень ценный комментарий, и у вас, возможно, больше опыта в этом вопросе, чем у меня. Но в нынешней ситуации наличие двойного текстового поля в качестве первичного ключа кажется действительно плохим выбором; я бы не хотел отлаживать запрос с соединениями в этой таблице :)
0x01AA
Спасибо за ваш ответ.
Бруно