SQL Частичный первичный ключ, составной ключ

В объекте author/title два «первичных» ключа должны действовать вместе как первичный ключ, как я могу это сделать в sql. Нужно ли мне создавать новый ключ, который поддерживает эти значения? Я знаю, что вам не разрешено иметь два первичных ключа в сущности, но я не знал, как писать, что они являются ключевыми ключами/частичными первичными ключами. Им с помощью SQL Server 2008SQL Частичный первичный ключ, составной ключ

Вот ссылка на эр диаграмме (http://img69.imageshack.us/img69/3048/68810818.png)

enter image description here

источник

2013-02-19 Dynamiite

Вы можете выбрать два атрибута в качестве первичного ключа или первичного ключа (автор, заголовок), должен помочь – scc

@spandy Если я делаю первичный ключ (автор, заголовок), то мне нужен новый ключ, который удерживает эти атрибуты. Как бы я выбрал эти атрибуты для работы в качестве первичного ключа без создания нового ключа. Спасибо за быстрый ответ. – Dynamiite

http://www.1keydata.com/sql/sql-primary-key.html - для «делать это из SQL». В SSMS выберите оба столбца из редактора таблицы и выберите «Основной ключ». – 2013-02-19 21:45:12

Не вдаваясь в правильности вас модели, композитный (ака. Соединение) первичный ключ может быть создан, как это :

CREATE TABLE "Author/Title" (
    author_name VARCHAR(50), 
    isbn VARCHAR(13) REFERENCES "Item Details", 
    PRIMARY KEY (author_name, isbn) 
)

Это позволит же author_name иметь различную isbn и по-прежнему считается уникальным (и наоборот).

Аналогичный эффект может быть выполнен с помощью SQL Server Management Studio путем маркировки обоих полей как части ПК.

источник

2013-02-19 21:49:08

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

@ DavidT.Macknet Суррогаты имеют свое место, но не являются бесплатными и не должны использоваться вслепую. Я полностью осведомлен о проблеме ON UPDATE CASCADE, но есть [другие соображения] (http://stackoverflow.com/tags/surrogate-key/info). –

«Суррогаты ... не являются бесплатными». Ну, нет, они не совсем свободны, за исключением определенных обстоятельств. В случае, если у вас нет кластерного индекса, SQL Server создает поле RowID в фоновом режиме, кластерный индекс в этом поле и отображает все остальные индексы в этот кластерный индекс. Таким образом, хотя вы этого не видите, стоить столько же, сколько построить таблицу ** без ** суррогата в этом случае. Если вы слишком обеспокоены или имеете дело с огромными наборами данных, я могу видеть, где вы хотите тщательно рассмотреть. Однако в вышеприведенном случае ожидается увеличение производительности плюс отсутствие каскадных потребностей. –

SQL Частичный первичный ключ, составной ключ

ответ

Смежные вопросы