更普遍地说，这只是需要在正确的数据设计和性能之间取得平衡的情况吗？
TL;DR “是的”。
关系模型与性能无关。数据的关系模型是一个正式的理论，它是许多数据模型之一。
数据模型是一个抽象的、自包含的、逻辑定义，它定义了用户与之交互的抽象机器中的对象、运算符等等。
抽象机器没有性能问题，因为它不存在于物理意义上。这就是为什么关系模型不涉及索引等问题的原因。
另一方面，SQL数据库与性能有很大关系。SQL数据库具有物理实现，其性能受核心数、内存量、磁盘空间、配置和主轴转速、并发用户数、索引等等因素的影响。
区别在于逻辑和物理，抽象和具体，以及原则和实践之间的区别。
所以是的，你需要在干净的设计和性能之间取得平衡。每个人都需要。
最好的方法是“先进行干净的逻辑（即关系）设计，然后作为单独的、随后的步骤，将该逻辑设计映射到目标DMBS支持的任何物理结构中。”
如果你必须存储计算结果，最佳做法是让SQL DBMS维护一致性。例如，如果你必须存储（数量*价格）+销售税的结果，则编写CHECK()约束以保证一致性。一些DBMS不支持CHECK()约束。
如果你必须在许多行之间维护总数，请使用物化视图。一些DBMS不支持物化视图。
在最坏的情况下，你只能使用一个人读取的报告来确定是否出现了不一致。这个人采取纠正措施。
在所有情况下，在进行更改之前和之后，测量代表性插入、更新和删除语句的性能。
最佳实践是让API查看每个洞来计算击中球道的数量，还是直接在球员表中存储击中球道的数量？
有很多统计数据。你应该将统计数据存储在一个或多个额外的表中。SQL DBMS不必“查看每个洞”；它们操作集合。
但是为了计算它，您需要每次都遍历该球员打过的每个洞吗？
不，你不需要“遍历每个洞”，至少不是迭代地遍历每个洞，尽管这正是许多前端应用程序框架所做的。你只需要一个单独的SQL查询，例如
select count(*) from player_holes where fairway_hit = True;。
[1]
数据库系统简介，第七版，C. J. Date，第14页
[2] 同上，第327页。
