使用多个查询而不是一个查询是否“可以”？ [关闭]答案

【问题标题】：Is it ever "ok" to use multiple queries instead of one? [closed]使用多个查询而不是一个查询是否“可以”？ [关闭]
【发布时间】：2013-09-13 15:20:21
【问题描述】：

最近在构建一个网络应用时，我开始考虑从我所做的查询返回的信息：

查找用户信息和（为简单起见）与该用户相关联的电话号码。一些简单的事情：

SELECT a.fname, a.lname, b.phone 
FROM users a 
JOIN users_phones b 
    ON (a.userid = b.userid) 
WHERE a.userid = 12345;

这里没问题（是的，我正在防止注射等，不是这个问题的重点）。但是，当我考虑返回的数据时，我（可能）返回了几行信息，每行都带有该用户名。假设单个用户有 1000 个与之关联的电话号码。这是每个电话都会返回的名字和姓氏。假设我想要返回的不仅仅是该用户的名字和姓氏，实际上我开始返回相当多的额外行，而我实际上只需要一次。

是否存在对数据库进行多次调用“更合适”的情况？

例如

SELECT firstname, lastname 
FROM users 
WHERE userid = 12345;

SELECT phone 
FROM users_phones 
WHERE userid = 12345;

如果答案是肯定的，是否有一种好的/适当的方法来确定何时使用多个查询而不是单个查询？

【问题讨论】：

我只是将其设为子查询并仅返回电话号码，将其包装在 SELECT phone FROM (......)
AFAIC，第 1 步：正确编写查询。不管你做 1 个数据库查询还是 1000 个，只要它是正确的。第 2 步：您的应用程序可能很慢。使慢的部分更快（但前提是你对“慢”有一个合理的定义。“慢”并不意味着“可能更快的东西”，而是“实际上导致问题的东西花费太长时间” )。

标签： mysql sql database join

【解决方案1】：

我认为这真的取决于您的用例。在您给出的示例中，将其作为两个查询返回似乎是有意义的，特别是如果您将该信息传递回移动设备，您希望确保向它们发送尽可能少的数据（不是每个人都有无限的数据.....）

如果这会根据您的表有所不同，我可能也会在这些查询中添加一个 DISTINCT。

【讨论】：

【解决方案2】：

带有JOIN 的查询可能比两个独立的查询慢。这实际上取决于您正在执行的访问类型。

对于您的示例，我将使用两种查询方法。这些查询可以并行执行，它们可以被缓存，并且没有真正的理由JOIN 除了任意表示问题。

您还需要担心返回重复数据。在您的示例中，看起来fname 和lname 会针对每个电话号码重复，从而导致传输大量实际上没有用的数据。这是因为您描述的一对多关系。

如果这意味着发送更少的数据，或者因为这两个查询不是独立的，通常你会想要JOIN。

【讨论】：

【解决方案3】：

这应该由应用程序驱动。基本上，您可以在一个查询中检索一个位置所需的所有信息。如果您以这个问题页面为例，您会看到您的用户 ID、信誉计数器和徽章计数器。首次显示问题页面时，无需检索其他用户个人资料信息。

只有单击用户 ID 才能查询到配置文件的其余部分，甚至可能不是全部，因为配置文件页面上有多个选项卡。

但是，如果保证您的应用程序可以同时访问所有 1000 个电话号码以及用户名，那么您可能应该将它们全部一起获取。

【讨论】：

除非我没有正确阅读您的内容，否则我仍然会在同一个“页面”中访问我需要的所有信息 - 它只是在 1 个调用或 2 个（或更多）中。在您的示例中，您假设信息没有显示在同一页面上（它是）。问题是返回 fname 和 lname 1000 次，因为该用户有 1000 个电话号码
我不确定您的担忧是什么。我有一种感觉，你不知何故不愿意使用连接。你不应该。只有当您担心额外的网络流量或内存使用来保留所有这些冗余名称时，您才有理由不使用连接。
我担心的是返回额外的不必要信息，以及应用程序中应指示哪些决定因素何时使用多个查询而不是单个查询。你基本上只是在重申我已经问过的问题。我不是“不愿意”使用连接。必要时，我一直在各种应用程序中使用它们。你最后的评论基本上告诉我你不明白这个问题，因为它只是在重申我的问题。
好吧，那你可能不明白我的回答。
我明白。我个人认为这是不正确的，并且在这里给出了 0 票，并且对基本上与您的最后一行相反的答案进行了投票。 “由应用程序驱动”是真的，我理解这一点。无论哪种方式，谢谢您的回答。