Ограничения внешнего ключа 1: 1

Question

Как указать, что ограничение внешнего ключа должно быть отношением 1: 1 в транзакции sql? Достаточно ли объявление столбца УНИКАЛЬНЫМ? Ниже мой существующий код.!

CREATE TABLE [dbo].MyTable(
    [MyTablekey] INT IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,
    [OtherTableKey] INT NOT NULL UNIQUE
        CONSTRAINT [FK_MyTable_OtherTable] FOREIGN KEY REFERENCES [dbo].[OtherTable]([OtherTableKey]),
    ...
    CONSTRAINT [PK_MyTable] PRIMARY KEY CLUSTERED 
    (
        [MyTableKey] ASC
    ) WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

Answer 1

Столбец внешнего ключа с ограничениями UNIQUE и NOT NULL, который ссылается на столбец UNIQUE, NOT NULL в другой таблице, создает отношение 1: (0 | 1), что, вероятно, является тем, что вам нужно.

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

Answer 2

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

Answer 3

@ Bosnic:

У вас есть таблица CLIENT, которая имеет отношение 1: 1 с таблицей SALES_OFFICE, потому что, например, логика вашей системы говорит об этом.

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

Действительно ли вы включили бы данные SALES_OFFICE в таблицу CLIENT?

Если у каждого КЛИЕНТА есть уникальный SALES_OFFICE, а у каждого SALES_OFFICE есть уникальный, уникальный КЛИЕНТ - тогда да, они должны быть в одной таблице. Нам просто нужно лучшее имя. ;)

А если другим таблицам нужно связать их самостоятельно с SALES_OFFICE?

Нет причин для этого. Свяжите ваши другие таблицы с CLIENT, поскольку у CLIENT есть уникальный SALES_OFFICE.

А как насчет лучших практик и шаблонов нормализации базы данных?

Это является нормализацией.

Честно говоря, SALES_OFFICE и CLIENT, очевидно, не являются отношениями 1: 1 - это 1: N. Надеемся, что ваш SALES_OFFICE существует для обслуживания более 1 клиента и будет продолжать существовать (по крайней мере некоторое время) без каких-либо клиентов.

Более реалистичным примером являются SALES_OFFICE и ZIP_CODE. SALES_OFFICE должен иметь ровно 1 ZIP_CODE, и 2 SALES_OFFICE - даже если они имеют эквивалентный ZIP_CODE - не должны совместно использовать экземпляр ZIP_CODE (поэтому изменение ZIP_CODE, равное 1, не влияет на другое). Разве вы не согласны с тем, что ZIP_CODE принадлежит как столбец в SALES_OFFICE?

Answer 4

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

Это очень неправильно. Позвольте привести пример. У вас есть таблица CLIENT, которая имеет отношение 1: 1 к таблице SALES_OFFICE, потому что, например, логика вашей системы говорит об этом. Вы действительно включили бы данные SALES_OFFICE в таблицу CLIENT? А если другим таблицам нужно связать их самостоятельно с SALES_OFFICE? А как насчет лучших практик и шаблонов нормализации базы данных?

Столбец внешнего ключа с ограничениями UNIQUE и NOT NULL, который ссылается на столбец UNIQUE, NOT NULL в другой таблице, создает отношение 1: (0 | 1), что, вероятно, вам и нужно.

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

Answer 5

Исходя из приведенного выше кода, будет достаточно уникального ограничения, учитывая, что для каждого первичного ключа, который есть в таблице, столбец уникальных ограничений также уникален. Также предполагается, что в [OtherTable] столбец [OtherTableKey] является первичным ключом этой таблицы.