假设您在数据库中有两个表，一个表用于高尔夫选手，一个表用于高尔夫球洞，以及一个API，该API必须返回诸如球手在其生命中命中的球道之类的东西。最好的方法是让API查看每个孔以计算球道命中数，或者仅将球道命中存储在玩家表中吗？似乎将这些数据存储在players表中基本上是在复制数据，因为它已经存在于每个孔中。但是，为了进行计算，您需要每次都经过玩家玩过的每个孔。
更笼统地说，这仅仅是您需要在正确的数据设计和性能之间取得平衡的情况吗？
我意识到这可能需要一个主观的答案（如果抱歉，那么就很抱歉），但是我对数据库设计的了解还不够，无法确定它们是否是对这种情况的明确答案。
更笼统地说，这仅仅是您需要在正确的数据设计和性能之间取得平衡的情况吗？
TL; DR“是”。
关系模型与性能无关。数据的关系模型是形式理论；它是许多数据模型之一。
甲数据模型是一个抽象的，自包含的，逻辑的对象，运营商定义，等等，其一起构成了抽象机与用户进行交互。[1]
抽象机器没有性能问题，因为它在物理意义上不存在。例如，这就是为什么关系模型对索引什么也没说。
另一方面，SQL数据库与性能有很大关系。SQL数据库具有物理实现，其性能受内核数影响。内存量；磁盘空间，配置和主轴速度；并发用户数；指标; 等等。
区别在于逻辑与物理之间，抽象与具体之间以及原理与实践之间的差异。
因此，是的，您需要在简洁的设计与性能之间取得平衡。每个人都这样。
最好的方法是“首先进行干净的逻辑（即关系）设计，然后作为一个单独的后续步骤，将该逻辑设计映射到目标DMBS碰巧支持的任何物理结构中。” [2]
如果必须存储计算结果，则最佳实践是使SQL DBMS保持一致性。例如，如果必须存储的结果(quantity * price) + sales_tax，则编写CHECK（）约束以确保一致性。一些DBMS不支持CHECK（）约束。
如果必须跨许多行维护计数（计数），请使用实例化视图。一些DBMS不支持实例化视图。
在最坏的情况下，您只能使用一个人阅读的报告来确定是否导致了不一致性。该人会采取纠正措施。
在所有情况下，请在进行更改之前和之后评估代表性的INSERT，UPDATE和DELETE语句的性能。
最好的方法是让API查看每个孔以计算球道命中数，或者仅将球道命中存储在玩家表中吗？
有很多统计数据。您可能应该将统计信息存储在一个或多个其他表中。SQL DBMS不必“查看每个漏洞”。他们按集操作。
但是，为了进行计算，您需要每次都经过玩家玩过的每个孔。
不，您不需要“遍历每个孔”，至少不需要遍历每个孔，尽管这正是许多前端应用程序框架所做的。您只需要一个SQL查询，例如select count(*) from player_holes where fairway_hit = True;。
[2]同上，第327页。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句