我应该使用复杂的SQL查询还是在应用程序中处理结果？
我正在处理一个应用程序，它的SQL查询非常复杂。复杂到我刚理解完一个查询，就已经忘记最开始是怎么回事了。
我在想，是否可以从数据库中提取更多数据，然后在我的代码里，比如用Python，来做最终的查询。这想法是不是太疯狂了？这样做会对性能造成很大的影响吗？
需要注意的是，结果也很庞大，我说的是一个由其他人开发的正在使用的ERP系统。
5 个回答
@Nivas 一般说得对。
这些情况是很常见的。
分工合作 - 数据库管理员（DBA）需要提供业务所需的所有数据，但他们只能使用数据库。开发人员本来可以和DBA合作，让事情做得更好，但由于部门职责的限制，这几乎是不可能的。所以，SQL 不仅仅用来获取数据。
缺乏小功能。能不能把这个庞大的查询拆分成几个小步骤，使用工作表？可以，但我见过一些环境中，创建一个新表需要很多审批，所以就直接写了一个复杂的查询。
总的来说，从数据库中获取数据是数据库的责任。但如果SQL查询太长，关系型数据库管理系统（RDBMS）就很难优化，可能意味着这个查询同时涉及数据、业务逻辑甚至展示。
我建议更合理的方法是把“给我数据”的部分分离出来，放到存储过程或其他可控的查询中，这些查询可以填充临时表。然后，业务逻辑可以用一种脚本语言来编写，控制这些存储过程，而展示部分则放在其他地方。实际上，像 Cognos 这样的解决方案本来就是想这么做的。
不过，如果你在看一个正在运行的企业资源计划（ERP）系统，上面提到的限制和解决方案可能已经存在了——你在和对的人沟通吗？
让数据库自己决定怎么最好地获取你想要的信息，否则你就得在代码里重复关系型数据库管理系统（RDBMS）的功能，这样会比写SQL查询复杂得多。
而且，你还会浪费时间把那些不需要的信息从数据库传到你的应用程序里，然后再在代码中进行筛选和处理。
这一切都是因为你提到你在处理大量数据。
我建议尽量把业务逻辑放在应用程序里。因为在查询中写复杂的业务逻辑会很难维护。每次我弄明白一个逻辑的时候，往往已经忘了最开始是怎么回事了。在存储过程里写复杂逻辑是可以的，但如果你用的是典型的Python应用，最好把业务逻辑放在Python里。
数据库在处理数据方面比你的应用代码要强得多。所以如果你的逻辑涉及大量数据，可能把逻辑放在数据库里会有更好的性能。这种情况通常出现在复杂的报告、记账操作等需要处理大量数据的场景。对于这些操作，你可能需要使用存储过程，或者一些专门处理这类操作的系统（比如用于报告的数据仓库）。
正常的在线事务处理（OLTP）操作涉及的数据量并不大。虽然数据库可能很大，但一次典型的交易所需的数据通常只是其中的一小部分。在大型数据库中查询这些数据可能会导致性能问题，但你可以通过多种方式来优化（比如使用索引、全文搜索、冗余、汇总表等……具体要看你的实际问题）。
每条规则都有例外，但作为一个一般的指导原则，尽量把业务逻辑放在应用代码里。复杂逻辑可以用存储过程来处理。对于报告，可以使用单独的数据仓库或一系列程序。