我应该编写更多SQL以提高效率，还是减少SQL以减少错误？

Question

我一直在编写大量的一次性SQL查询，以准确地返回某个页面需要的内容，而不是更多内容。

我可以重用现有的查询，并发出一些与页面上的记录数呈线性关系的SQL请求。作为示例，我有一个返回People的查询和一个查询以返回一个人的工作详细信息。要返回包含其工作详细信息的人员列表，我可以为人员查询一次，然后为每个人查询一次以查找他们的工作详细信息。我发现在大多数情况下，解决方案会在合理的时间内返回内容，但我不知道它在我的环境中的扩展程度。相反，我一直在编写查询以加入人员+工作细节，或人员+工资历史等。

我正在查看我的模型，如果我要重新使用现有查询，我会看到如何削减30％的代码。这是一个很大的诱惑。一般来说重复使用效率是不是一件坏事，还是归结为具体情况？我应该先以简单的方式进行，然后再进行优化，还是最好将代码删除，而我脑子里的一切都是新鲜的？思想，经历？

Answer 1

这样的建筑决策总是取决于具体情况。但作为一般规则，应始终避免在一个数据集上循环以便检索其他数据。连接通常具有更好的性能 - 尤其是在Web服务器和数据库服务器之间存在网络延迟的情况下。

如果您仍想要单独查询，则至少应通过WHERE IN (...)构造构造第二个实体的提取，以便一次获取所有行。

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

Answer 2

如果它们适用于您的编程环境，我会考虑使用O / RM解决方案，那么您根本不需要编写太多SQL。

Answer 3

两者。您做出的每一个决定都将根据要求选择合适的路径。

例如，在大多数系统中，通常你会有两类视图 - 提供基本层的视图（子系统中的一些连接，最小的工作，没有聚合，最小的数据屏蔽）（没有ISNULL（datecol，'1/1） / 1900'））和提供完全封装的视图（聚合，来自不同子系统的数据连接，符合数据）。

在这些情况下，您可能会对基础层进行大量重复使用（但更频繁的更改），从而进行良好的测试并确保它们可靠且重复使用较多（但更少频繁的更改）水平抽象，相应减少测试和保证。

基本视图将被编码以获得最高效率，因为使用模式不是可预测的，更高级别的视图将具有更少的用例，因此在某些类型的情况下可能仅需要效率。

Answer 4

编写新的查询以提高效率，并将结果与​​经过验证的测试查询进行比较，以保持质量。

如果截止日期很短，你会选择质量而不是效率，并使用经过验证的真实质量，因为它们可以帮助你节省开发时间和测试时间。