为了保持我的代码DRY，我目前有多个单独的查询，他们有自己的责任。这使我能够使用这些查询的组合执行复杂的操作，而不是编写仅针对这些操作自定义的更大的查询。
类似于在代码中使用可重用/动态方法，而不是为每个特定用例编写一个方法。它使开发变得更容易，但可能会牺牲一些性能。
注意：我不是为了DRY而保持干燥。我试图保持动态，易于阅读和理解。
简化示例：
我需要获取员工和部门的权限组。然后，我需要获得这些权限组的权限关联。我还需要获得分配给员工或部门的细化权限（与权限组无关的权限）。
我可以编写2个查询来获取权限组及其关联的权限，还有2个查询可以直接获得与员工和部门相关联的权限。这些不可用于其他目的。
或者我可以编写1个查询来获取员工或部门的权限组，1个查询获取与任何权限组关联的权限，1个查询可以获得与员工/部门本身相关联的权限。
这是一个简化的例子。在实践中，我将有15个以上的案例特定查询和15个执行。 Vs 5动态查询和~40次执行。
以这种方式解决问题是否存在性能问题？代码本身看起来更干净，更容易使用，但我不想为更干净的dev-API牺牲大量的DB性能。
答案 0 :(得分：0)
您应该尝试使用每页请求尽可能少的查询。即使它们速度很快，想象一下你在页面上有5个查询执行对40个。如果有1000个人点击该页面，那就是请求的5000个查询与40,000个查询。是的，你可以打开缓存，但我不会依赖它。即使它已启用，使用较少的查询仍可提高性能。如果你必须检索5个缓存查询的结果，这显然比检索40的结果更快。只要你的索引被正确定义并且是最新的，如果你必须进行一些连接，你的查询应该仍然快速运行。我想无论你得到哪些答案，你仍然应该试错并记录结果。如果我们在这里谈论毫秒差异，并且你每分钟都没有得到数千个页面请求，那么这真的很重要吗？
答案 1 :(得分：0)
对于网页来说，几十个简单的查询并不算太多。
尝试两种方式。尝试第三种方法来查询。让这成为一个学习练习。没有必要采用“正确”的方式来设计/编码您所描述的内容。
DRY是一个很好的原则，但它太复杂了。因此，寻找各种方法之间的“适当平衡”。
常见的口号是“避免过早优化”。