Составные ключи БД с Entity Framework 4.0

При перепроектировании большой базы данных в нашей компании широко используются составные первичные ключи в базе данных.

Если забыть о влиянии на производительность, вызовет ли это какие-либо трудности при работе с этой базой данных в Entity Framework 4.0? Структура базы данных вряд ли изменится, и я не ищу «философских» дебатов, но каковы практические последствия?

Согласно Джереми Миллер," Составной ключ усложняет любой вид объектно-реляционного сопоставления и стойкость в целом ". но на самом деле он не говорит почему. Связано ли это с тем, как Entity Framework 4.0 обрабатывает ключи?


entity-framework primary-key composite-key
person Steve Ward    schedule 18.12.2009    source источник

Ответы (2)


arrow_upward
13
arrow_downward

Нет, EF4 отлично поддерживает составные ключи.

Проблема в таблице с суррогатным ключом и составными ключами. Вы можете установить только один ключ для каждой модели; этот ключ может иметь несколько полей, но с точки зрения дизайнера может быть только одно. Не уверен в ручном редактировании xml или сопоставлении только кода.

Вы можете установить поле как удостоверение, а не как ключ, если вам нужен составной и суррогатный ключ в одной таблице. Поле Identity (Id) не будет использоваться ObjectContext или ObjectStateTracker, но при этом будет увеличиваться и его можно будет запросить.

person John Farrell    schedule 18.12.2009

arrow_upward
8
arrow_downward

У меня были проблемы с EF4 и составными ключами. Он не поддерживает использование столбцов в качестве компонентов более чем в одном ключе объединенной таблицы.

См. Мой предыдущий вопрос Сопоставление составных внешних ключей в отношении "многие-многие" в Entity Framework для получения дополнительных сведений. Суть этого в том, что когда у вас есть таблица соединений (описывающая отношение "многие-многие"), в которой оба отношения используют общий ключ, вы получите ошибку типа

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

Единственный способ обойти это - продублировать столбец, который вообще лишает его смысла.

Удачи!

person Kirk Broadhurst    schedule 12.10.2010