Редизайн для большой базы данных в нашей компании широко использует составные первичные ключи в базе данных.
Забыв о влиянии на производительность, это вызовет какие-либо трудности при работе с этим БД в Entity Framework 4.0? Структура базы данных вряд ли изменится, и я не ищу «философских» дебатов, но каковы практические последствия?
По словам Джереми Миллера , «составной ключ усложняет любые виды объектно-реляционного отображения и персистентности в целом» но он на самом деле не говорит, почему. Относится ли это к тому, как Entity Framework 4.0 обрабатывает ключи?
Нет, EF4 прекрасно поддерживает составные ключи.
Проблема в таблице с суррогатным ключом и составным ключом. Вы можете установить только один ключ для каждой модели; этот ключ может иметь несколько полей, но вы можете иметь только одно с точки зрения дизайнера. Не уверен насчет ручного редактирования XML или сопоставления только кода.
Вы можете установить поле в качестве идентификатора, а не ключа, если вам нужен составной и суррогатный ключ в одной таблице. Поле Identity (Id) не будет использоваться ObjectContext или ObjectStateTracker, но будет увеличиваться и, тем не менее, отлично выполнять запросы
У меня были проблемы с EF4 и составными ключами. Он не поддерживает использование столбцов в качестве компонентов в нескольких ключах таблицы соединений.
См. Мой предыдущий вопрос « Отображение составных внешних ключей во многих-многих отношениях в Entity Framework» для получения более подробной информации. Суть в том, что когда у вас есть таблица соединений (описывающая отношение многие-многие), где оба отношения используют общий ключ, вы получите сообщение об ошибке типа
Ошибка 3021: проблема в сопоставлении фрагментов ...: Каждый из следующих столбцов в таблице PageView сопоставлен с несколькими концептуальными свойствами стороны: PageView.Version сопоставлен с (PageView_Association.View.Version, PageView_Association.Page.Version)
Единственный способ обойти это - дублировать колонку, что лишает ее цели.
Удачи!