何时将连接操作从数据库层移到服务层？

Question

考虑到这个情况，我们有两张桌子。需要实现一个函数，从TABLE_A和TABLE_B ( table_a.id == table_b.a_id == X )中选择前10条记录(按某些规则排序)。有两种选择：

1. 使用JOIN查询SQL；
2. 从db：SELECT * FROM table_a WHERE id = X和SELECT * FROM table_b WHERE a_id = X进行2次选择查询，从内存中从每个查询中获取10条记录(在本例中我们假设排序是正确的)，然后在代码中加入它们(使用for循环和散列表之类的方法)。

我听说JOIN可能会降低系统的性能(这里是"db性能“，但这是错误的)(请参阅下面的后续参考)。此外，在这种情况下，我们只查询最多10个结果，这是可以接受的，将它们全部加载到内存中，然后在那里加入它们。

我的问题是，在这个行业中是否有一个通用的指导方针:在什么情况下我们建议在数据库层中使用JOIN而不是在内存中使用它，以及何时进行相反的操作？

============

后续行动：

下面是我所读到的“将连接从数据库层移到服务层”的原因/场景：

如果我们加入多个表，

1. 将同时锁定多个表。如果操作耗时且服务需要较低的响应时间，则可能会阻止其他executions;
2. Hard在大系统中进行维护。对涉及到broken.
3. There的表的更改可能会使查询JOIN成为这些复杂系统的历史原因，数据可能在不同的db (或db系统，如DynamoDB中的一个表和Postgres中的另一个表)中迁移/创建，这使得数据库层中的JOIN无法实现。

Answer 1

简单地回答，这取决于.

通常，

• 更倾向于做更接近数据的数据操作，而不是将它们提升到更高的层次，并处理数据操作。您可以看到许多基于PL/SQL的实现，它们在这些实现中进行更接近数据的操作。PL/SQL(ORACLE)或TSQL( Server)等语言被设计用于执行复杂的数据操作。但是，如果您有一个应用程序，它从不同的系统中获取数据，并且必须在它们之间连接，则必须在内存中进行这些操作。

1. If we are joining multiple tables, they will all be locked at once. And if the operation take times and the service requires low response time, it might block other executions;

读者不会阻止其他读者。他们有一种叫sharedlock的东西。而且，一旦读取操作结束，共享锁就会被释放。作为@TimBiegeleisen，您可以根据需要创建索引以加快读取操作。最好只读取需要的列(投影)、所需的行(筛选)。

1. 很难在大系统中维护。连接中涉及的表的更改可能会导致查询中断.

只要您只选择所需的列，而不是SELECT *，您就不会出现问题。如果需要进行许多更改，可以考虑创建架构绑定视图，以避免对底层表进行架构更改。

1. 可能是这些复杂系统的历史原因，数据可能在不同的db (或db系统，例如DynamoDB中的一个表和Postgres中的另一个表)中迁移/创建，这使得在数据库层中加入是不可能的。

根据当前的需要设计应用程序。不要假设将来会发生类似的事情，并为此而设计，并影响当前的应用程序性能。如果将来有明确的需求，就进行内存中的操作.否则，最好选择数据库连接。