Чи допустимо мати кругові посилання на іноземні ключі \ Як їх уникнути?

Чи прийнятно мати кругову посилання між двома таблицями на зовнішньому ключовому полі?

Якщо ні, то як уникнути цих ситуацій?

Якщо так, то як можна вставити дані?

Нижче наведено приклад того, де (на мою думку) кругла посилання була б прийнятною:

CREATE TABLE Account
(
    ID INT PRIMARY KEY IDENTITY,
    Name VARCHAR(50)
)

CREATE TABLE Contact
(
    ID INT PRIMARY KEY IDENTITY,
    Name VARCHAR(50),
    AccountID INT FOREIGN KEY REFERENCES Account(ID)
)

ALTER TABLE Account ADD PrimaryContactID INT FOREIGN KEY REFERENCES Contact(ID)

Оскільки ви використовуєте нульові поля для зовнішніх ключів, ви можете насправді побудувати систему, яка працює правильно, як ви її уявляли. Для того, щоб вставити рядки в таблицю облікових записів, вам потрібно мати рядок, присутній у таблиці "Контакти", якщо ви не дозволяєте вставляти в облікові записи з нульовим PrimaryContactID. Щоб створити рядок контактів, не маючи при цьому рядка облікового запису, потрібно дозволити, щоб стовпець AccountID у таблиці "Контакти" був зведений нанівець. Це дозволяє обліковим записам не мати контактів, а контактам - не мати облікового запису. Можливо, це бажано, можливо, ні.

Сказавши це, моїм особистим уподобанням було б таке налаштування:

CREATE TABLE dbo.Accounts
(
    AccountID INT NOT NULL
        CONSTRAINT PK_Accounts
        PRIMARY KEY CLUSTERED
        IDENTITY(1,1)
    , AccountName VARCHAR(255)
);

CREATE TABLE dbo.Contacts
(
    ContactID INT NOT NULL
        CONSTRAINT PK_Contacts
        PRIMARY KEY CLUSTERED
        IDENTITY(1,1)
    , ContactName VARCHAR(255)
);

CREATE TABLE dbo.AccountsContactsXRef
(
    AccountsContactsXRefID INT NOT NULL
        CONSTRAINT PK_AccountsContactsXRef
        PRIMARY KEY CLUSTERED
        IDENTITY(1,1)
    , AccountID INT NOT NULL
        CONSTRAINT FK_AccountsContactsXRef_AccountID
        FOREIGN KEY REFERENCES dbo.Accounts(AccountID)
    , ContactID INT NOT NULL
        CONSTRAINT FK_AccountsContactsXRef_ContactID
        FOREIGN KEY REFERENCES dbo.Contacts(ContactID)
    , IsPrimary BIT NOT NULL 
        CONSTRAINT DF_AccountsContactsXRef
        DEFAULT ((0))
    , CONSTRAINT UQ_AccountsContactsXRef_AccountIDContactID
        UNIQUE (AccountID, ContactID)
);

CREATE UNIQUE INDEX IX_AccountsContactsXRef_Primary
ON dbo.AccountsContactsXRef(AccountID, IsPrimary)
WHERE IsPrimary = 1;

Це забезпечує можливість:

1. Чітко розмежуйте відносини між контактами та обліковими записами через таблицю перехресних посилань, як рекомендує Пітер у своїй відповіді
2. Підтримуйте референтну цілісність на здоровий, некруговий спосіб.
3. Забезпечте високомобільний список первинних контактів через IX_AccountsContactsXRef_Primaryіндекс. Цей індекс містить фільтр, тому він працюватиме лише на платформах, які їх підтримують. Оскільки цей індекс визначено UNIQUEопцією, для кожного облікового запису завжди може бути лише один основний контакт.

Наприклад, якщо ви хочете відобразити список усіх контактів, зі стовпцем, що позначає "первинний" статус, із первинними контактами вгорі списку для кожного облікового запису, ви можете зробити:

SELECT A.AccountName
    , C.ContactName
    , XR.IsPrimary
FROM dbo.Accounts A
    INNER JOIN dbo.AccountsContactsXRef XR ON A.AccountID = XR.AccountID
    INNER JOIN dbo.Contacts C ON XR.ContactID = C.ContactID
ORDER BY A.AccountName
    , XR.IsPrimary DESC
    , C.ContactName;

Відфільтрований індекс запобігає введенню більш ніж одного первинного контакту на акаунт, одночасно забезпечуючи швидкий метод повернення списку первинних контактів. Можна легко уявити собі інший стовпець IsActiveз унікальним відфільтрованим індексом для підтримки історії контактів за обліковим записом, навіть після того, як цей контакт більше не пов’язаний з обліковим записом:

ALTER TABLE dbo.AccountsContactsXRef
ADD IsActive BIT NOT NULL
CONSTRAINT DF_AccountsContactsXRef_IsActive
DEFAULT ((1));

CREATE INDEX IX_AccountsContactsXRef_IsActive
ON dbo.AccountsContactsXRef(IsActive)
WHERE IsActive = 1;

Ні, неприпустимо мати кругові посилання на іноземні ключі. Не тільки тому, що було б неможливо вставити дані, не постійно скидаючи та відтворюючи обмеження. а тому, що це принципово хибна модель будь-якого домену, про який я можу придумати. У вашому прикладі я не можу придумати жоден домен, у якому зв’язок між обліковим записом та контактом не є NN, і для цього потрібна таблиця з'єднання з посиланнями FK назад як на обліковий запис, так і на контакт.

CREATE TABLE Account
(
    ID INT PRIMARY KEY IDENTITY,
    Name VARCHAR(50)
)

CREATE TABLE Contact
(
    ID INT PRIMARY KEY IDENTITY,
    Name VARCHAR(50),
)

CREATE TABLE AccountContact
(
    AccountID INT FOREIGN KEY REFERENCES Account(ID),
    ContactID INT FOREIGN KEY REFERENCES Contact(ID),

    primary key(AccountID,ContactID)
)

Ви можете мати ваш зовнішній об’єкт вказувати на основний контакт, а не на рахунок. Ваші дані виглядатимуть приблизно так:

CREATE TABLE Account
(
    ID INT PRIMARY KEY IDENTITY,
    Name VARCHAR(50)
)

CREATE TABLE Contact
(
    ID INT PRIMARY KEY IDENTITY,
    Name VARCHAR(50),
    AccountID INT FOREIGN KEY REFERENCES Account(ID)
)

CREATE TABLE AccountOwner (
    Other Stuff Here . . .
    PrimaryContactID INT FOREIGN KEY REFERENCES Contact(ID)
)