我们有一个包含太多行的数据库表。为了加快性能，我们正在尝试创建一个汇总表。这适用于一对一的关系。例如假设furniture有一个type和一个manufacturer_id，您可以拥有一个包含这两列和counts列的表格。查询该表很容易，并且很快得到给定类型的家具数量。
但是，如果存在多对多关系怎么办？所以每件家具也可以有一个或多个colors和一个或多个distributors。那会发生什么？有没有办法总结这些数据，所以我可以很快找到有多少家具是绿色的？或者有多少是蓝色和黄色？
显然这只是一个例子。但是如果给出一个包含数百万行的巨大的数据库表，我该如何创建一个汇总表来快速查找汇总信息呢？
答案 0 :(得分：1)
假设您知道自己在做什么，并且知道这是一个真正的瓶颈：您现在对性能进行了测量吗？你知道它从哪里开始花时间吗？
无论如何，您必须查询数据库才能获得该数据。因此，您可以将其存储在单独的表中，如颜色计数和分配器数量。另一种解决方案是将这些查询的结果缓存在缓存系统中。例如，如果您已经使用了memcached或其他一些工具。
最简单的当你拥有一个数据库就是创建一个表：
table color count
color_id
amount
这是一个非常简单的查询。您可以很好地索引它，并且不需要连接。
可以使用触发器，cron或更新多对多表来完成更新。根据您的需求和容量。考虑到更新记录也需要时间，因此请用它来优化读取，这就是我在你的问题中所读到的。
答案 1 :(得分：0)
多个表应该保持大小...并且一个好的数据库系统应该保持性能提升。
在我看来，保留一个单独的“汇总表”会产生很多开销和维护问题，并且只有在需要反复提供相同的摘要信息时才会真正有用（即，有多少家具是绿色的而不存储多少是蓝色，有多少是黄色，有多少是蓝色和黄色等，等等。）
我要做的是：
表1：家具
表2：经销商
表3：颜色
表4：家具经销商
表5：家具颜色
有多少家具是绿色的：
SELECT COUNT（*）FROM furniture-color WHERE colorUniqueIDvalue ='green ID';
有多少家具都是蓝色和黄色：
SELECT COUNT（*）FROM furniture-color as t1 INNER JOIN furniture-color as t2 ON t1.furnitureUniqueIDvalue = t2.furnitureUniqueIDvalue AND t1.colorUniqueIDvalue ='blue ID'AND t2.colorUniqueIDvalue ='yellow ID';
使用正确的SQL语句（左侧作为读者的练习）获取蓝色和黄色家具的分销商或来自特定经销商的绿色或红色家具或大多数其他东西的经销商列表。
答案 2 :(得分：0)
您需要区分计算不同类型的家具（不同的家具ID）和计算实际的家具。
如果您有经销商颜色表，那么您可以计算实际的家具。但是，您不能计算不同类型的家具。这是OLAP术语中附加事实和非附加事实之间的区别。如果您对此主题感兴趣，请查看Ralph Kimball及其经典着作“数据仓库工具包”。
要计算家具类型，您需要将其包含在表格中。所以，你需要一个经销商色彩家具桌。现在要获得经销商的总数，您可以使用：
select distributor, count(distinct furnitureid)
from dcf
group by distributor
同样适用于颜色。
您似乎希望将原始数据转换为每个报告的事实表。这是开发数据集市的一个非常好的标准想法。您的数据集市可能有两个事实表。一种用于每种类型的家具（因此您可以轻松处理制造问题）和其他用于经销商的颜色家具（用于更难的问题）。
某些数据库（如Oracle和SQL Server）支持这些类型的数据结构。你所谈论的更像是一个新的“系统”，而不仅仅是一个新的“桌子”。您需要考虑事实表的维度，更新以及所需的报告类型。
答案 3 :(得分：0)
颜色汇总表中可能有 2 ^ n 行，其中'n'是颜色数。如果将颜色缩小为位图并为每个颜色指定一个位置（红色= 0，橙色= 1，黄色= 2，绿色= 3等），则颜色汇总表可以是：
Color Count
0x0001 256
0x0002 345
0x0003 23839
etc.
256只有红色，345只有橙色，23,839有红色和橙色。要获得有多少具有红色但可能有其他颜色的计数，需要将位置0的行相加。或者，可以设置一个单独的汇总表，只有'n'个条目，每个颜色一个，以避免对行进行求和。
如果您希望汇总表管理分销商和颜色，那么我认为它将具有 2 ^ n * 2 ^ m 行（其中'm'是分销商的数量）多个家具的多个经销商的组合，每个家具可能有多种颜色。