Отображение составных внешних ключей в отношениях многие-многие в Entity Framework

Question

У меня есть таблица страниц и таблица просмотра. Существует много-много взаимосвязей между этими двумя через таблицу PageView. К сожалению, все эти таблицы должны иметь составные ключи (по деловым причинам).

• Страница имеет первичный ключ (PageCode, Version),
• View имеет первичный ключ (ViewCode, Version).
• Очевидно, что PageView имеет PageCode, ViewCode и Version.
• FK для страницы - это (PageCode, Version), а FK для просмотра - (ViewCode, Version)

Имеет смысл и работает, но когда я пытаюсь отобразить это в Entity Framework, я получаю

Ошибка 3021: проблема в отображении фрагменты ...: каждый из следующих столбцы в таблице PageView отображается на несколько концептуальных побочных свойств: PageView.Version отображается на (PageView_Association.View.Version, PageView_Association.Page.Version)

Совершенно очевидно, что EF жалуется на то, что столбец Version является общим компонентом двух внешних ключей.

Очевидно, что я мог бы создать столбец PageVersion и ViewVersion в таблице соединений, но этот тип побеждает точку ограничения, т. Е. У Page и View должно быть одинаковое значение Version.

Кто-нибудь сталкивался с этим, и могу ли я что-нибудь обойти? Спасибо!

Answer 1

Мне неизвестно о решении в Entity Framework для этой проблемы, но обходным путем может быть добавление столбцов первичного ключа в таблицы и добавление уникальных ограничений на поля, которые вы хотите действовать как составной ключ. Таким образом, вы гарантируете уникальность ваших данных, но при этом все еще имеете один столбец первичного ключа. Pro-con аргументы можно найти в этой теме: stackoverflow вопрос

Приветствия

Answer 2

После большого прочтения и возни, это всего лишь ограничение дизайнера и валидатора EF при работе со многими-многими связями.

Answer 3

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

Если вы выполняете на сервере, который поддерживает ограничения, вы можете разделить Версию на PageVersion и ViewVersion и добавить ограничение, что они равны, или использовать триггер INSERT / UPDATE, чтобы применить это.

Возможно, я просто неправильно понял намерение, но я чувствую, что есть кое-что, что кажется неправильным с этим дизайном. Я не могу себе представить, как будет работать управление версиями при изменении страниц и представлений и создании новых версий. Если изменение страницы означает, что она получает новую версию, то это также приведет к созданию новых версий всех ее представлений, даже для представлений, которые не изменились в этой версии. Эквивалентно, если изменяется одно представление на странице, изменяется версия представления, что означает, что версия страницы также должна изменяться, и поэтому все другие представления на этой странице, так как версии страницы и представления должны совпадать. Это кажется правильным?

Answer 4

Рассмотрите возможность использования nHibernate? :) - или хотя бы для чего-то большего, чем простые объединения в вашей БД. Я работаю с EF4, и он пока не выглядит достаточно зрелым для сложных графиков данных IMO. Надеюсь, он все же доберется!