Как я могу использовать один и тот же первичный ключ для двух таблиц?
Я читаю книгу по EF4, и я столкнулся с этой проблемной ситуацией:
![enter image description here]()
Поэтому мне было интересно, как создать эту базу данных, чтобы я мог следовать примеру из книги.
Как бы я создал эти таблицы, используя простые команды TSQL? Забудьте о создании базы данных, представьте, что она уже существует.
Ответы
Ответ 1
Когда он говорит, что в таблицах используется один и тот же первичный ключ, это означает, что в каждой таблице есть одно и то же имя, оба установлены как первичные ключи.
Создать таблицы
CREATE TABLE [Product (Chapter 2)](
SKU varchar(50) NOT NULL,
Description varchar(50) NULL,
Price numeric(18, 2) NULL,
CONSTRAINT [PK_Product (Chapter 2)] PRIMARY KEY CLUSTERED
(
SKU ASC
)
)
CREATE TABLE [ProductWebInfo (Chapter 2)](
SKU varchar(50) NOT NULL,
ImageURL varchar(50) NULL,
CONSTRAINT [PK_ProductWebInfo (Chapter 2)] PRIMARY KEY CLUSTERED
(
SKU ASC
)
)
Создать отношения
ALTER TABLE [ProductWebInfo (Chapter 2)]
ADD CONSTRAINT fk_SKU
FOREIGN KEY(SKU)
REFERENCES [Product (Chapter 2)] (SKU)
Это может выглядеть немного проще, если имена таблиц - это просто одиночные слова (а не ключевые слова)), например, если имена таблиц были просто Product
и ProductWebInfo
, без добавления (Chapter 2)
:
ALTER TABLE ProductWebInfo
ADD CONSTRAINT fk_SKU
FOREIGN KEY(SKU)
REFERENCES Product(SKU)
Ответ 2
Вам предоставлен код. Я хочу поделиться некоторой информацией о том, почему вы можете иметь две таблицы в таких отношениях.
Сначала, когда две таблицы имеют один и тот же первичный ключ и имеют отношение внешнего ключа, это означает, что они имеют взаимно-однозначное отношение. Так почему бы просто не положить их в один стол? Существует несколько причин, по которым вы можете разделить некоторую информацию на отдельную таблицу.
Сначала информация концептуально раздельна. Если информация, содержащаяся во второй таблице, связана с отдельной конкретной проблемой, это упрощает работу с ней, данные находятся в отдельной таблице. Например, в вашем примере они отделили изображения, даже если они предназначены только для одной записи для каждого SKU. Это дает вам гибкость, позволяющую легко изменить таблицу позже на отношения "один-много" , если вы решите, что вам нужно несколько изображений. Это также означает, что при запросе только для изображений вам не нужно фактически ударять другую (возможно, значительно большую) таблицу.
Это приводит нас к разуму, чтобы сделать это. В настоящее время у вас есть отношения один-один, но вы знаете, что в будущем релизе уже запланировано превратить это в отношения "один-много" . В этом случае проще создать отдельную таблицу, чтобы вы не разбивали весь свой код при переходе к этой структуре. Если бы я планировал это сделать, я бы продолжил и создавал суррогатный ключ в качестве ПК и создавал уникальный индекс в FK. Таким образом, когда вы переходите к отношениям "один-много" , все, что вам нужно сделать, это сбросить уникальный индекс и заменить его на обычный индекс.
Еще одна причина для разделения отношения "один-один" - это если таблица становится слишком широкой. Иногда у вас просто слишком много информации об объекте, который легко вписывается в максимальный размер, который может иметь запись. В этом случае вы, как правило, берете наименее используемые поля (или те, которые концептуально подходят друг другу) и перемещают их в отдельную таблицу.
Еще одна причина для их исключения состоит в том, что, хотя у вас есть отношения один-один, вам может не понадобиться запись того, что находится в дочерней таблице для большинства записей в родительской таблице. Поэтому вместо того, чтобы иметь много нулевых значений в родительской таблице, вы разделите ее.
Код, показанный другими, предполагает персональную PK. Если вам нужна такая связь, когда у вас есть автогенерирующий Int или GUID, вам нужно сделать автогенерирование только в родительской таблице. Затем вы храните это значение в дочерней таблице, а не генерируете новое в этой таблице.
Ответ 3
Это просто пример, который я собрал вместе с помощью конструктора таблиц в SSMS, но должен дать вам представление (обратите внимание на ограничение внешнего ключа в конце):
CREATE TABLE dbo.Product
(
SKU int NOT NULL IDENTITY (1, 1),
Description varchar(50) NOT NULL,
Price numeric(18, 2) NOT NULL
) ON [PRIMARY]
ALTER TABLE dbo.Product ADD CONSTRAINT
PK_Product PRIMARY KEY CLUSTERED
(
SKU
)
CREATE TABLE dbo.ProductWebInfo
(
SKU int NOT NULL,
ImageUrl varchar(50) NULL
) ON [PRIMARY]
ALTER TABLE dbo.ProductWebInfo ADD CONSTRAINT
FK_ProductWebInfo_Product FOREIGN KEY
(
SKU
) REFERENCES dbo.Product
(
SKU
) ON UPDATE NO ACTION
ON DELETE NO ACTION
Ответ 4
Посмотрите, как создать ограничение внешнего ключа. http://msdn.microsoft.com/en-us/library/ms175464.aspx Это также имеет ссылки на создание таблиц. Вам также потребуется создать базу данных.
Чтобы ответить на ваш вопрос:
ALTER TABLE ProductWebInfo
ADD CONSTRAINT fk_SKU
FOREIGN KEY (SKU)
REFERENCES Product(SKU)