【问题标题】:Best SQL Option for Performance性能最佳 SQL 选项
【发布时间】:2011-03-27 22:25:17
【问题描述】:

我目前需要执行一个数据库查询,该查询涉及来自三个单独表的数据。 (bases,member,sell_transaction)

bases 表如下所示

base_id(PK)    名称    状态

member 表如下所示

id(PK)    last_name    用户名   电子邮件    first_name

sell_transaction 表具有以下架构

transaction_id(PK)    城市 状态 base_id 日期    ID 代理ID

注意 - 这些表包含更多列,但它们无关紧要,因此我将节省时间而不是将它们写出来。

我正在处理涉及所有这些表中的数据的事务查询。我需要在从这三个表中填充的 TransactionItem 中返回这些数据

作为 Pojo 的 TransactionItem 如下所示

公共事务项(){ 私人字符串名; 私人字符串姓氏; 私人字符串电子邮件; 私有字符串基名; 私人字符串城市; 私有字符串状态; 私人日期日期; 公共字符串 getFirstName(){ 返回名字; } 公共字符串 setFirstName(字符串名字){ this.firstName = 名字; } ... ...///其余的 getter 和 setter ... ... }



目前我正在从每个表中进行三个单独的选择,这比我想要的要花费更长的时间。我想有一种方法可以使用连接或嵌套选择语句等。

数据和条件及其对应的表格如下

我需要...

first_name, last_name,id 来自 member

我需要

namestate 来自 bases 其中 base_id 来自 sell_transaction 等于 base_id 来自 基地

我还需要更多,但将它们命名是多余的,这个想法应该仍然很清楚,我需要查询相互依赖的数据。我不确定性能方面的最佳选择是什么。被遍历的数据量最终可能非常大或非常小(不确定这是否重要)。

选择 b.name,b.state, s.city,s.state,s.duty,s.branch,s.date, m.first_name,m.last_name,m.email,m.phone,m.id,s.transaction_id 从 基础为 b,sell_transaction 为 s,成员为 m 在哪里 s.agentId 为 null 并且 s.username = m.username 和 b.base_id = s.duty

【问题讨论】:

  • 为什么你在多个表中有状态?它们是相同的数据吗?如果是这样,哪个表应该是规范来源?
  • AgentID 的关系是你的 Member 表的外键吗?
  • 它们不是同一个数据,它们有不同的含义

标签: java sql mysql


【解决方案1】:
select first_name, last_name, member.id member_id, bases.name, bases.state
from bases, sell_transaction, member
where sell_transaction.base_id = bases.base_id
and member.id = sell_transaction.agentId;

我要在这里冒险,猜测 agentID 是从 sell_transactionmember 的连接,但它并不清楚或不明显,并且可能不正确(除非你澄清您的数据模型)。​​

【讨论】:

  • agentId 不是与member的连接,其实我没有列出来,但是sell_transaction表中还有一个id列引用了member中的id列
  • @CitadelCSAlum:如果您忽略重要的列,我们将很难提供帮助。您有两个“我需要...”语句,但不清楚您是想要两个单独的结果集还是一个。我假设是一个,因为这是通常需要的,听起来你只想要一个查询。也许您可以提供预期结果的样本,以及您当前使用的查询。
  • 对不起,我没有故意省略重要的列,我真的在寻找更好的选择的建议,我可以做嵌套选择语句,我可以做类似于上面语句的事情,或者我可以做一个三重连接类型的语句。在这三个中,有一个明显优于另一个。
  • CitadelCSAlum:同样,如果不了解您的系统,很难知道哪种策略最适合您。尝试编写所有三个查询并通过查询分析器运行它们以查看哪个执行得最好。如果您为这些列中的任何一个建立了索引,也会对性能产生影响。
  • 我已经用我一直在使用的查询编辑了上面的内容,希望它能让您更好地了解我在使用什么。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-03-08
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-02-17
相关资源
最近更新 更多