Microsoft T-SQL не поддерживает более одного первичного ключа;Предлагаемые обходные пути? - PullRequest
Новая
       61

Microsoft T-SQL не поддерживает более одного первичного ключа;Предлагаемые обходные пути?

0 голосов
/ 10 декабря 2018

Я читал блестящий ответ, предоставленный PerformanceDBA на этот SQL-вопрос .

В PerformanceDBA «Полный пример», таблицы «пользователь» и «спорт» показывают два ПЕРВИЧНЫХ КЛЮЧЕЙ на таблицу. Примечание;если вы внимательно посмотрите на ответ PerformanceDBA , вы заметите, что Первичный Ключ Один состоит из одного поля, а Первичный Ключ Два состоит из трех полей;составной ключ.

Учитывая Microsoft T-SQL Сервер не поддерживает более одного Первичный ключ на таблицу (я не знал, что SQL ANSI тоже), как бы мы достигли концепции, представленной PerformanceDBA в качестве работоспособного Microsoft T-SQL решения (то есть, следуя Microsoft T-SQL синтаксис)?

Есть ли вероятность, что информация, предоставленная PerformanceDBA , просто содержит опечатку;ошибка, которую он пропустил?

Мои первоначальные мысли (определение таблицы из PerformanceDBA ответ на SQL-вопрос с незначительными изменениями для соответствия T-SQL): 

    CREATE TABLE [User] (              -- Typical Identifying Table
       [user_name]  CHAR(16) NOT NULL, -- Short PK
       name_first CHAR(30) NOT NULL,   -- Alt Key.1
       name_last  CHAR(30) NOT NULL,   -- Alt Key.2
       birth_date DATE     NOT NULL ,  -- Alt Key.3

        --Create a unique CONSTRAINT and assign a Foreign Key (
       CONSTRAINT User_PK  PRIMARY KEY ( [user_name] ),

       -- Will this 'do'?
       CONSTRAINT User_AK  UNIQUE  ( name_last, name_first, birth_date ),

       CONSTRAINT user_FK -- unique person identification
          FOREIGN KEY (name_last, name_first, birth_date) 
          REFERENCES [Person] ( name_last, name_first, birth_date) 

     )

Спасибо, что уделили время.

Ответы [ 2 ]

0 голосов
/ 21 декабря 2018

По тому, как вы пишете этот вопрос, легко понять, что вы действительно знаете, о чем говорите: ANSI / SQL / Microsoft T-SQL, первичные ключи против уникального индекса.

Ваш вопрос ясени вы предоставили не только серьезную справочную информацию по вашему вопросу, но и предоставили одно краткое решение;задача, которую многие не пытаются выполнить как часть первоначального вопроса.

Я прочитал ответ PerformanceDBA, и ваш вопрос остается;Какой индекс должен был быть первичным ключом, а какой - индексом (УНИКАЛЬНЫМ) (и должен ли он быть УНИКАЛЬНЫМ индексом)?

В этом сценарии я подозреваю, что имя_пользователя является желаемым Первичным ключом, учитывая, что он не только должен быть уникальным, но во многих системах индивидуальный вход в систему ДОЛЖЕН быть уникальным.В этом сценарии имя, отчество и DOB становятся внешним ключом (УНИКАЛЬНЫЙ ИНДЕКС).

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

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

0 голосов
/ 10 декабря 2018

В Microsoft SQL Server мало или нет различий между ключом, созданным как PRIMARY KEY, и ключом, созданным с использованием ограничения UNIQUE (конечно, для столбцов, не допускающих значения NULL).Вы можете определить до 1000 уникальных ограничений на таблицу.Существует одно или два незначительных различия в синтаксисе, но нет особой причины использовать ограничение PRIMARY KEY вместо ограничения UNIQUE.

...