Создает навигационные отношения в базе данных плохой практики?

Question

Я использую EF4.3/Sql Server 2008 Web.

Я пытался создать нормированную базу - вот его раздел:

Как вы можете увидеть общий фактор в том, что все они связаны через BuyerId. В EF я могу перемещаться по этой структуре с помощью «Buyer.MatchBuyer.MatchNodes» и т. Д., Однако я задавался вопросом, считалось ли, что неправильная практика создает дополнительные отношения исключительно с целью дальнейшего упрощения этой навигации.

Например, добавление отношения между LenderMatchNode и Buyer на BuyerId.

Все рекомендации оценены.

Answer 1

Я бы сказал, что это действительно не очень хорошая идея делать в базе данных. Если вы используете фреймворк сущности, вы можете использовать «Разделение таблиц» для достижения такой же функциональности без использования нечетной структуры базы данных.

Это хороший учебник:

http://weblogs.asp.net/manavi/archive/2011/04/24/associations-in-ef-4-1-code-first-part-4-table-splitting.aspx

И есть другие, на блоге Скотт Гатри:

http://weblogs.asp.net/scottgu/

EDIT: Вот учебник я упомянул:

http://weblogs.asp.net/scottgu/archive/2010/07/23/entity-framework-4-code-first-custom-database-schema-mapping.aspx

Вы можете проверить сценарий три. Думаю, это то, за чем ты был.

EDIT: комментарий Герта Арнольдса заставил меня передумать немного.

Может быть следующим:

Покупатель

BuyerId 
Name 
Status 
BuyerTypeId 
RequestClass 
AcceptQuota 
TierId 
Commission 

MatchNode

BuyerId 
TierId 
Enabled 
RuleClass 

Вы тогда 1: N для Покупателя-MatchNode и, возможно, составной ключ на покупателя?

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