我们使用Len Silverston的Data Model Resource Book Vol中的两种模式在SQL Server中构建了一个数据库。 3，类型和类别之一：分类，另一个用于层次结构，聚合和点对点关系。从本质上讲，它的含义如下：
分类
[实体]（M x M）[实体类型]（M x M）[实体类型]
...其中（M x M）是分类表在数据库中实现的多对多关系。
协会
上面的实体和类型表也有自己的类型化汇总：
...其中每个（M x M）是在Rollup表中实现的多对多关系，其中包含汇总/关联类型的外键。
由此产生的数据结构在描述我们的实体及其相互关系方面为我们提供了极大的表达能力。但是，我们在应用程序中无法利用这种表现力。主要问题是，尽管EF 4＆amp; 5，M-2-M关系仍然很棘手，除此之外我们试图在我们到达数据库时至少在两个方向上访问M-2-M。特别复杂的是：
技术：
有关模型本身的问题：
关于打字方案的问题 - 请记住这些类型非常静态：
非常感谢任何想法或经验！
答案 0 :(得分：2)
我尝试回答每个问题，但我不得不承认我不确定您是否在运行时尝试在数据库之上动态创建实体 - 或者您是否只是尝试动态创建实体运行时间。
如果您尝试发布在SQL Server中的架构发生更改时动态更改/调整的代码，那么我会有一些不同的答案。 =）
这只是.NET中一个不可行的数据模型吗？
你提到的一些事情让我很突出：
阅读后我有些问题：
我不知道您的域名，但我知道我很难按照您的描述进行操作。 =）在我看来，由于两个原因，它已经变得有些不可行了：1）你问的是关于它的问题，b）没有大量的文字就不容易描述。
我们是否应该首先将我们的数据库展平为更多.NET友好视图，这些视图基本上模拟我们的业务对象？
是的！
至少从我的经验来看，我会说是的。 =）
我认为在数据库中创建具有复杂关系的实体是可以的。父母/子女，点对点，等级等等。一切都很好，正常。
但应用程序不应该解释所有这些来理解它。数据库擅长连接，分组数据，创建视图等。我建议创建尽可能接近业务对象的视图或存储过程 - 至少对于读取来说。
还要考虑如果将相关对象的复杂性推向应用程序，则可能会产生一些性能损失。
我们应该将[EntityType]和[EntityTypeType]表，它们的分类以及它们汇总到C＃类中吗？
我会反对这一点。唯一的原因是现在您正在应用程序层中进行数据库工作。如果你想做连接/汇总/等。你在应用程序中管理这些数据 - 而不是数据库。
我确定您已经知道这一点，但是您希望避免将数据库中的所有内容都恢复到应用程序中，然后然后运行查询/构建对象。
SQL Server在关联对象和将不同实体拉在一起时非常棒。在那一层它会非常快。
我会创建业务对象并从SQL填充它们。
如果您需要构建EntityType / EntityTypeType，请注意不要遇到N + 1问题。
关于如何构建这些文件的一些想法 - 作为静态类？硬编码对象列表？
选项：
我们是否应该在启动时缓存打字方案（这让我感到烦恼，因为它增加了启动控制台应用程序的大量开销）？
您想在应用程序加载时根据您的实体生成业务对象吗？或者另一种表达问题的方法......在运行时生成代理类？
答案 1 :(得分：1)
我不熟悉Len Silverston的书，我认为StackOverflow用户绝大多数都不是。由于你在3天内没有得到你的问题的答案，我现在无论如何都会对它发表评论。
在数据库模型中，奇怪的是你似乎有多个嵌套的N：M关系。很少有真正的N：M关系 - 大多数情况下，N：M关系模型中的中间表实际上代表了现实生活中存在的一个对象，留下了两个常规的1：N关系，而不仅仅是两个列链接表。在过去的25年里，我只遇到过一两个真正的N：M关系，所以我有点怀疑你实际上有三个 - 这似乎更有可能是你使用的模式不适用于你认为它的方式。
你所描述的有点像你试图在数据库中建模数据库。特别是“我们应该首先将我们的数据库压缩成更多.NET友好视图，这些视图基本上模拟我们的业务对象吗？听起来很腥。除了极少数例外，您的数据库表应该与您的业务对象匹配。如果您需要创建展平视图以查看实际对象，则可能完全朝向错误的方向。但话又说回来，很难从你提供的信息中分辨出来。
请简要介绍一下您正在尝试做什么，到目前为止您做了什么。