我正在尝试找出访问连接对象中存储的数据的最快方法。下面的示例与我的问题类似，但具有不同的上下文，因为我正在处理的实际数据集的关系有些不直观。
我们有 3 个类:User、Product 和 Rating。用户与 Product 具有多对多关系，以 Rating 作为连接/“通过”类。
Rating 对象存储几个问题的答案，这些问题是 1-5 级的整数评级(示例问题:产品 的质量如何，如何是Product的值，Product的用户友好程度)。为了简化起见，假设每个用户都对他们购买的每个产品进行评分。
现在这是我要执行的计算:对于用户，计算他们购买的所有产品的平均评分(即平均评分来自所有其他用户，其中之一将来自该用户他们自己)。然后我们可以告诉用户“平均而言，您购买的产品被所有购买该产品的客户评为 3/5 的值(value)”。
简单而缓慢的方法就是迭代用户的所有评论对象。如果我们假设每个用户购买了少量(<100)件产品，并且每个产品有 n 个评分，则 O(100n) = O(n)。
但是，我也可以执行以下操作:在 Product 类上，保留选择每个数字的 Rating 数量的计数器(例如有多少 >用户对该产品的值(value)评分为 3/5)。如果每次对 Product 进行评级时都会增加该计数器，则计算给定 Product 的平均值只需检查每个 Rating 的 5 个计数器标准。
这是一种有效的技术吗？它是否常用/有名称吗？这对我来说似乎很直观，但我对数据库了解不够，无法判断是否存在一些根本性缺陷。
最佳答案
这是正常的。它最终是缓存:对状态进行冗余编码，以牺牲其他使用模式为代价，使某些使用模式受益。当然这也是一种复杂化。
仅仅因为 RDBMS 数据结构是关系，并不意味着您不能从某种简单的形式重新安排状态编码方式。例如非规范化。
(有时，冗余设计(包括像您这样的设计)被称为“非规范化”，因为它们实际上并不是非规范化的结果，并且冗余不是非规范化导致或规范化删除的那种。 Cross Table Dependency/Constraint in SQL Database 事实上，人们可以合理地描述您的案例涉及标准化而不保留 FD(功能依赖性)。从包含用户的 id 和其他列、他们的 评级(关系)及其 计数器 的表开始。然后， ratings 在功能上确定 counter，因为 counter = select count(*) from ratings。分解到 user 等 + counter，即表 User 和 user + ratings，它将取消分组到表Rating。)
Do you have a suggestion as to the best term to use when googling this
我经常发表的评论:用各种术语和标签子集搜索您的问题/问题/目标/需求的许多清晰、简洁和具体的措辞，因为您可能会发现它们带有或不带您的特定名称(变量/数据库/表/列/约束/等)。例如“我什么时候可以在数据库中冗余存储(总和或总计)”。人类的措辞，而不仅仅是关键词，似乎都有帮助。您最好的选择可能是优化 SQL 数据库设计以提高性能。有整本书(“amazon isbn”)，一些在线书籍(“pdf”)。 (但也许主要是重新查询)。研究与仓储相关的技术，因为 OLTP 数据库充当 OLAP 数据库的输入缓冲区，并将 SQL 与大数据结合使用。 (例如快照调度。)
PS 我称其为“缓存”(标签 caching 也是如此)(对我来说)是相当抽象的，以至于有一些严肃的笑话认为 CS 中的所有内容都是缓存。 (谷歌搜索...“计算机科学中只有两个难题:缓存失效和命名事物。”--Phil Karlton。)(欢迎两者。)
关于database - 我可以在数据库多对多字段中使用计数器来减少查找吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45407402/