client-server - 一个复杂查询与多个简单查询

Question

实际上更好的是什么？让具有复杂查询的类负责加载例如嵌套对象？或者具有负责加载简单对象的简单查询的类？

对于复杂的查询，您不必去数据库，但该类将承担更多责任。

或简单的查询，您需要更多地访问数据库。然而，在这种情况下，每个类都将负责加载一种类型的对象。

我所处的情况是加载的对象将被发送到 Flex 应用程序（DTO）。

Answer 1

这里的一般经验法则是服务器往返是昂贵的（相对于典型查询需要多长时间），因此指导原则是您希望将它们最小化。基本上，每个一对多连接都可能使您的结果集成倍增加，因此我的方法是继续连接，直到结果集变得太大或查询执行时间变得太长（通常大约 1-5 秒）。

根据您的平台，您可能会也可能无法并行执行查询。这是您应该做什么的关键决定因素，因为如果您一次只能执行一个查询，那么分解查询的障碍就会高得多。

有时值得在内存中保留某些相对恒定的数据（例如国家信息）或将它们作为单独的查询进行，但根据我的经验，这是相当不寻常的。

更常见的是不得不修复性能糟糕的系统，这在很大程度上是由于执行单独的查询（特别是相关查询）而不是连接。

Answer 2

我认为没有任何选择实际上更好。这取决于您的应用程序特定、架构、使用的 DBMS 和其他因素。

例如，我们在独立解决方案中使用了多个简单查询。但是当我们将产品发展为轻量级的互联网可访问解决方案时，我们发现我们的框架发出了大量的请求，并且导致网络延迟的性能下降。因此，我们充分改造了我们的框架以使用聚合的复杂查询。同时，我们仍然维护我们的独立解决方案，并从 Oracle Light 迁移到 Apache Derby。我们再一次发现我们的一些新的复杂查询应该被简化，因为 Derby 执行它们的时间过长。

所以看看你真正的问题并适当地解决它。我认为，如果没有针对它们的强有力的目标，那么简单的查询是很好的开始。

Answer 3

凭直觉我会说：

只要没有经过证实的优化性能的理由，就使用简单的方法。否则，我会将“复杂对象和查询”方法放在过早优化的篮子中。

如果您发现存在真正的性能影响，那么您应该在下一步优化 flex 和后端之间的往返。但正如我之前所说：这是一种直觉，你真的应该从“性能”的定义开始，从简单开始并衡量性能。