Sql Server Составной первичный ключ - PullRequest
1 голос
/ 07 августа 2009

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

Table: Listings
Primary Key: MlsNumber (int), MlsBoard (int)
Foreign Key: PK Table: Listings (MlsNumber, MlsBoard) FKTable: Listings(MlsNumber, MlsBoard)

Когда я увидел это, я предположил, что случайно создал его в какой-то момент. Затем я нашел то же самое в еще 4 таблицах в той же базе данных. Я единственный человек, который может изменить эту базу данных, и это не то, что я сделал намеренно. Я заметил, что в каждом случае, где я его нашел, он был на столе с составным первичным ключом. У меня есть много других таблиц в той же базе данных, которые имеют составные первичные ключи и не содержат этот нечетный внешний ключ.

Кто-нибудь знает, что могло бы создать это? Сервер SQL Server 2008.

Ответы [ 2 ]

1 голос
/ 07 августа 2009

Мне кажется, я нашел причину, и, по мнению IMO, это очень плохое дизайнерское решение, сделанное людьми Microsoft.

Я пошел, чтобы создать новый внешний ключ и установить таблицу первичного ключа и таблицу внешнего ключа и их столбцы. Затем я понял, что мне нужно очистить данные в таблице перед созданием внешнего ключа, и щелкнул «Закрыть». Я обнаружил, что это создает ожидающий внешний ключ, как я описал в моем вопросе, FK, состоящий из полей первичного ключа, ссылающихся на себя.

Итак, я могу с полным основанием предположить, что произошло то, что в какой-то момент на этих 5 таблицах я начал создавать FK, подумал, что прервал эту операцию, когда приблизился, и затем сделал другое изменение в таблице, такое как добавив поле или изменив тип данных, а затем, когда я сохранил таблицу, я создал непреднамеренный FK. Могу добавить, что это был FK с параметрами, которые я никогда не задавал.

На мой взгляд, это ошибка.

Редактировать: Я только что обнаружил, что это на самом деле хуже, чем я описал. Даже если вы нажмете кнопку «Отмена» в диалоговом окне создания внешнего ключа, он все равно создаст внешний ссылочный внешний ключ в состоянии ожидания. Это ужасно глупо.

Редактировать 2: Чем больше я расследую, тем хуже становится. Я только что получил его, чтобы сохранить один из этих самоссылающихся FK, закрыв SSMS и нажав «Нет» в диалоговом окне «Сохранить изменения». Я снова открыл SSMS, и самопровозглашенный FK был создан в любом случае. Напомню, что я нажал кнопку «Отмена» в диалоговом окне создания FK и «Нет» в диалоговом окне сохранения изменений, и он создал внешний ключ с параметрами, которые я никогда не задавал.

1 голос
/ 07 августа 2009

Если поля FK ссылаются на другой набор из двух полей в одной таблице, то это представляет собой самостоятельное соединение. Например, если таблица сотрудников имела составной первичный ключ (скажем DivisionId и EmployeeId, где employeeIds были уникальными только в каждом подразделении), а затем вы хотели, чтобы каждая запись сотрудника идентифицировала руководителя сотрудника - как еще одну строку та же таблица.

Тогда каждая запись должна иметь составной ключ ForeignKey (SupervisorDivisionId, SupervisorId) для идентификации руководителя сотрудника.

Если эти два поля FK ссылаются друг на друга, то для этого нет веской причины, так как структура ограничений таким образом будет ВСЕГДА удовлетворена (она не может быть ложной.) И поэтому бессмысленна.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...