我应该写更多的SQL来提高效率,还是应该写更少的SQL来减少bug?

像这样的体系结构决策总是取决于具体情况。但作为一般规则,应始终避免在一个数据集上循环以检索额外的数据。加入通常具有更好的性能,尤其是在web服务器和DB服务器之间存在网络延迟的情况下。

如果仍然希望有单独的查询,则至少应该通过 WHERE IN (...) 构造,以便一次获取所有行。

代码重复总是很糟糕,SQL查询往往非常相似,但并不完全相同。我认为,使用ORM工具,即使是像Linq-to-SQL这样的基本工具,也有助于减少专门查询的开销。

如果它们可用于您的编程环境,我会考虑使用O/RM解决方案,那么您根本不必编写太多SQL(如果有的话)。

二者都您所做的每一个决定都将根据需求选择合适的路径。

例如,在大多数系统中,通常有两类视图-提供基本层的视图(子系统内的一些连接、最小工作量、无聚合、最小数据屏蔽(无ISNULL(datecol,'1/1/1900'))和提供完全封装的视图(聚合、来自不同子系统的数据连接、数据一致性)。

在这些情况下,您可能会对基础层进行大量重用(但更频繁的更改),从而进行良好的测试和保证,确保它们是可靠的,对更高级别的抽象进行较轻的重用(但不频繁更改),并相应地减少测试和保证。

基本视图将被编码以获得最高的效率,因为使用模式不那么可预测,更高级别的视图将有更少的用例,因此可能只在某些类型的用例中需要效率。

为了提高效率,编写新的查询,并将结果与经过测试的真实查询进行比较,以保持质量。

如果最后期限很短,你会选择质量而不是效率,并使用久经考验的方法,因为它们可以节省你的开发时间和测试。