Отображение составных внешних ключей во много-многих отношения в Платформе Объекта
У меня есть Таблица страниц и таблица View. Существуют много-многие отношения между этими двумя через таблицу PageView. К сожалению, все эти таблицы должны иметь составные ключи (по бизнес-причинам).
- Страница имеет первичный ключ (PageCode, Версия),
- Представление имеет первичный ключ (ViewCode, Версия).
- PageView, достаточно очевидно, имеет PageCode, ViewCode и Версию.
- FK к Странице (PageCode, Версия), и FK для Просмотра (ViewCode, Версия)
Имеет смысл и работы, но когда я пытаюсь отобразить это в платформе Объекта, я добираюсь
Ошибка 3021: проблема в отображающихся фрагментах...: Каждый из следующих столбцов в таблице PageView отображается на нескольких концептуальных свойствах стороны: PageView. Версия отображается на (PageView_Association. Представление. Версия, PageView_Association. Страница. Версия)
Так достаточно ясно, EF имеет жалование на столбец Version, являющийся общим компонентом этих двух внешних ключей.
Очевидно, я мог создать столбец PageVersion и ViewVersion в объединяющей таблице, но такие поражения точка ограничения, т.е. Страница и Представление должны иметь то же значение Версии.
Кто-либо встретился с этим и является там чем-нибудь, что я могу сделать, обходят его?Спасибо!
3 ответа
Мне не известно о решении этой проблемы в Entity Framework, но обходным путем может быть добавление столбцов первичного ключа в ваши таблицы и добавление уникальных ограничений для полей, которые вы хотите использовать. как составной ключ. Таким образом вы обеспечите уникальность ваших данных, но при этом у вас останется один столбец первичного ключа. Аргументы сторонников могут быть найдены в этой теме: stackoverflow question
Cheers
Рассмотрите возможность использования nHibernate? :) - или, по крайней мере, для чего-то большего, чем простые джойны в вашей БД. Я работаю с EF4, и на данный момент он не кажется достаточно зрелым для сложных графов данных IMO. Надеюсь, что это произойдет!
Я собирался написать, что вам следует использовать суррогатный ключ, но я не думаю, что это действительно поможет вам.Таблица соединения обеспечивает соблюдение бизнес-правила, основанного на логических атрибутах сущностей - эти же атрибуты будут храниться в таблице соединения, даже если страница и представление были дополнены суррогатными ключами.
Если вы выполняете работу на сервере, который поддерживает ограничения, вы можете разделить версию на PageVersion и ViewVersion и добавить ограничение, чтобы они были равны, или использовать триггер INSERT / UPDATE для обеспечения этого.
Возможно, я просто неправильно понял намерение, но я чувствую, что есть что-то, что не кажется правильным с этим дизайном. Я не могу представить, как будет работать управление версиями при изменении страниц и представлений и создании новых версий. Если изменение страницы означает, что она получает новую версию, это также приведет к созданию новых версий всех ее представлений, даже для представлений, которые не изменились в этой версии. Точно так же, если одно представление на странице изменяется, изменяется версия представления, что означает, что версия страницы также должна измениться, и, следовательно, все другие представления на этой странице, поскольку версии страницы и представления должны совпадать. Это кажется правильным?