Подтвердить что ты не робот

Как я могу использовать один и тот же первичный ключ для двух таблиц?

Я читаю книгу по EF4, и я столкнулся с этой проблемной ситуацией:

enter image description here

Поэтому мне было интересно, как создать эту базу данных, чтобы я мог следовать примеру из книги.

Как бы я создал эти таблицы, используя простые команды TSQL? Забудьте о создании базы данных, представьте, что она уже существует.

4b9b3361

Ответ 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)