我正在开发一个相当大的应用程序项目，我正在设置我的数据库以允许执行良好的查询。我有一个规范化的数据库结构，我知道随着我的数据集的增长会导致速度问题。我的数据库使用Entity Framework映射到我的ASP MVC项目。让我举一个我面临的困境的例子：
我有一张桌子，我们称之为Buildings。 Buildings可以是多种不同类型，例如房屋，公寓，酒店，汽车旅馆等。每栋建筑物大约有20个可能的多对一子房产（例如，评论，评论，电话号码）等等。）。现在，每种类型的建筑物的数量可能会有很大差异，例如，假设我预计只有100套公寓，而不是100,000间房屋。如果我像这样布置我的结构：
选项1：
buildings---->(condos, houses, etc)----->many-to-one properties.
其中包含建筑类型的表的中间层只包含建筑物的外键引用（或者等效地，将建筑类型包括为建筑物列），那么这意味着如果我想对建筑物进行搜索房子类型，我必须不必要地搜索建筑物表中的许多记录。
PROS：不太复杂的应用程序逻辑和数据库。
缺点：使更简单的查询更慢，建筑物表的损坏可能会影响整个应用程序。
选项2：
(condos, houses, etc)----->many-to-one properties.
完全跳过建筑物表并为每种建筑类型创建一个单独的表。每个数据结构都是相同的，但存储在其中的数据对于每个表都是唯一的（因此仍然标准化）。这里的问题是，我需要为每种建筑类型的20多个多对一属性中的每一个创建表。
PROS：对较小类型的查询速度快，无论其他类型大小如何，所有类型都没有单点故障，可以根据需要对每种类型应用自定义规则，必要时可以应用不同的索引（例如，类型上的非聚簇索引）可能会被频繁删除，例如可供出租的建筑物。）
CONS：更复杂的应用程序逻辑（可能通过存储过程接口减少）和db结构
考虑到这些权衡，您认为应该是一个应该能够支持大约40,000个并发用户的应用程序中更有价值的数据结构吗？还有另外一种方法可以做到这一点吗？
答案 0 :(得分：0)
理想情况下，您应该为插入，更新和删除保留高度规范化的操作数据库，以最大限度地减少重复和异常，并提高完整性并插入/更新/删除性能。
然后，您可以拥有一个非规范化数据仓库式数据库，用于选择，搜索，分析和分布在多个服务器上。
您可以使用物化视图来简化ETL到仓库，以创建非规范化查询，并按照计划（例如每天晚上）刷新物化视图。