Отсутствует отношение FK в модели Entity Framework

Question

У меня было много проблем с реализацией методики, описанной в статье Александра Кузнецова .По сути, в статье описан способ создания FK между одной таблицей и альтернативными таблицами, при этом сохраняются полные ограничения для этих отношений.

Вот часть кода Александра:

CREATE TABLE dbo.Vehicles(
    ID INT NOT NULL, 
    [Type] VARCHAR(5) NOT NULL,
    CONSTRAINT Vehicles_PK PRIMARY KEY(ID),
    CONSTRAINT Vehicles_UNQ_ID_Type UNIQUE(ID, [Type]),
    CONSTRAINT Vehicles_CHK_ValidTypes CHECK([Type] IN ('Car', 'Truck'))
)

CREATE TABLE dbo.Cars(ID INT NOT NULL,
    [Type] AS CAST('Car' AS VARCHAR(5)) PERSISTED,
    OtherData VARCHAR(10) NULL,
    CONSTRAINT Cars_PK PRIMARY KEY(ID),
    CONSTRAINT Cars_FK_Vehicles FOREIGN KEY(ID, [Type])
    REFERENCES dbo.Vehicles(ID, [Type])
)

* * * * * * * * * * * * * * * * * * * * * * * * * * После того, как все исправлено и исправлено.Но когда я генерирую свои модели EF из новой схемы, отсутствует связь между двумя моими таблицами.

Проблема в том, что для того, чтобы иметь FK на двух столбцах, необходимо must быть индексом или уникальным ограничением для обоих этих столбцов.Однако в моем случае у меня также есть другая таблица с FK для одного столбца в базовой таблице (Транспортные средства, в коде Александра).

Поскольку в таблице не может быть более одного PK, это означает, чтоЯ не могу иметь FK для PK с обеих сторон.PK может быть для одного или двух столбцов, а другой FK должен будет ссылаться на уникальное ограничение не-PK.

К сожалению, Entity Framework будет создавать для вас отношения только тогда, когда существует FK для PK.Это проблема.Может ли кто-то, кто понимает дизайн БД лучше, чем я, обнаружил здесь другие альтернативы?

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

Answer 1

Вы не можете иметь более одного PK, но вы можете иметь более одного уникального ограничения, а в SQL Server вы можете создать ограничение внешнего ключа, которое ссылается на уникальное ограничение (один или несколько столбцов).Вот пример двух таблиц, которые примерно похожи на вашу модель.

CREATE TABLE dbo.Vehicles
(
    VehicleID INT PRIMARY KEY,
    [Type] VARCHAR(5) NOT NULL UNIQUE,
    CONSTRAINT u1 UNIQUE(VehicleID, [Type])
);

CREATE TABLE dbo.Cars
(
    CarID INT PRIMARY KEY,
    VehicleID INT NOT NULL
        FOREIGN KEY REFERENCES dbo.Vehicles(VehicleID),
    [Type] VARCHAR(5) NOT NULL
        FOREIGN KEY REFERENCES dbo.Vehicles([Type]),
    CONSTRAINT fk1 FOREIGN KEY (VehicleID, [Type])
        REFERENCES dbo.Vehicles(VehicleID, [Type])
);

Обратите внимание, что у Cars есть три внешних ключа: один указывает на PK транспортных средств (VehicleID), один указывает на уникальное ограничение для транспортных средств ([Type]), а другой указывает на несколько столбцов.уникальное ограничение для транспортных средств (VehicleID, [Type]).Я понимаю, что это не эквивалентно тому, что вы пытаетесь сделать, но должно продемонстрировать, что SQL Server, по крайней мере, способен делать все, что вы, кажется, хотите сделать (мне трудно понять, что вы на самом деле, потому что выпродолжайте обмениваться понятиями между тем, что сделал Алекс, тем, что вы пытаетесь сделать, но терпите неудачу, и тем, что вы сделали успешно.Если это так, влияет ли это на ограничения, которые имеют более одного столбца, или на все уникальные ограничения?Если это так, то это позор, потому что это, безусловно, поддерживается в SQL Server.Похоже, это будет либо ошибка, либо преднамеренное упущение (учитывая, что стандарт строго не допускает использование FK против уникальных ограничений).Интересно, есть ли какие-либо сообщения об ошибках в Connect ?

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