代码之家 › 专栏 › 技术社区 › Community wiki

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

sql

Community wiki · 技术社区 · 1 年前

我一直在写很多一次性的SQL查询,以准确地返回某个页面所需要的内容,而不再需要更多。

我可以重用现有的查询,并根据页面上的记录数量线性地发出许多SQL请求。例如,我有一个返回人员的查询和一个返回某个人的工作详细信息的查询。要返回一个带有工作详细信息的人员列表,我可以查询一次人员,然后为每个人查询一次,以检索他们的工作详细信息。我发现,在大多数情况下,该解决方案会在合理的时间内返回内容,但我不知道它在我的环境中的扩展效果如何。相反,我一直在写查询,以加入人员+工作详细信息,或人员+薪资历史记录,等等。

我正在研究我的模型,我发现如果我重用现有的查询,我可以如何减少大约30%的代码。这是一个巨大的诱惑。一般来说,追求重用而非效率是一件坏事吗?还是这一切都归结为特定的情况?我应该先用简单的方法做,然后再优化,还是最好在一切都还新鲜的时候把代码删掉?思想、经历?

4 回复 | 直到 15 年前

Anders Abel 15 年前

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

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

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

BlackICE 15 年前

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

Cade Roux 15 年前

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

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

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

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

Marcus Adams 15 年前

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

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