我正在尝试了解通过面向对象的构建器 DSL 构建 SQL 与参数化原始 SQL 字符串相比的优势。在以三种方式研究/实现相同的查询之后，我注意到原始 SQL 是迄今为止最容易阅读的。这就引出了一个问题，“为什么要跳过一个箍？”为什么不直接声明和使用原始 SQL？

这是我想出的:

首先，我猜它使 SQL 更具可移植性，因为它可以被任何带有适配器的数据库使用。我猜这是大人物，对吧？尽管如此，难道大多数 T-SQL 不是大多数数据库都能理解的吗？

其次，它提供了一个可以重复使用的查询对象——作为其他查询、命名范围链接等的基础。

通过构建 SQL 而不是声明 SQL，您实现的主要投资返回是什么？

def instances_of_sql(ttype_id) #raw sql
  ttype_id = get(ttype_id).try(:id)
  ti   = get('tmdm:type-instance')
  inst = get('tmdm:instance')
  type = get('tmdm:type')

  self.class.send :sanitize_sql, [%{
    SELECT t.*
    FROM associations a
    JOIN roles type    ON type.association_id = a.id AND type.ttype_id = ?
    JOIN roles inst    ON inst.association_id = a.id AND inst.ttype_id = ?
    JOIN topics t      ON t.id = inst.topic_id
    WHERE a.topic_map_id IN (?)
    AND a.ttype_id    = ?
    AND type.topic_id = ?
  }, type.id, inst.id, self.ids, ti.id, ttype_id]
end

def instances_of_sql(ttype_id) #sequel
  ttype_id = get(ttype_id).try(:id)
  ti = get('tmdm:type-instance')
  ir = get('tmdm:instance')
  tr = get('tmdm:type')

  DB.from(:associations.as(:a)).
    join(:roles.as(:tr), :tr__association_id => :a__id, :tr__ttype_id => tr[:id]).
    join(:roles.as(:ir), :ir__association_id => :a__id, :ir__ttype_id => ir[:id]).
    join(:topics.as(:t), :t__id => :ir__topic_id).
    where(:a__topic_map_id => self.ids).
    where(:a__ttype_id => ti[:id]).
    where(:tr__topic_id => ttype_id).
    select(:t.*).sql
end

def instances_of_sql(ttype_id) #arel
  ttype_id = get(ttype_id).try(:id)
  ti   = get('tmdm:type-instance')
  inst = get('tmdm:instance')
  type = get('tmdm:type')

  #tables
  t    = Topic.arel_table
  a    = Association.arel_table
  tr   = Role.arel_table
  ir   = tr.alias

  a.
    join(tr).on(tr[:association_id].eq(a[:id]),tr[:ttype_id].eq(type[:id])).
    join(ir).on(ir[:association_id].eq(a[:id]),ir[:ttype_id].eq(inst[:id])).
    join(t).on(t[:id].eq(ir[:topic_id])).
    where(a[:topic_map_id].in(self.ids)).
    where(a[:ttype_id].eq(ti[:id])).
    where(tr[:topic_id].eq(ttype_id)).
    project('topics.*').to_sql
end

我非常欣赏命名作用域并了解链接它们的好处。我不担心通过模型访问相关记录。我纯粹是在谈论构建一个复杂的查询。

最佳答案

@Kyle Heironimus 给 Nick Kallen 关于 Arel 的想法的链接有这样一行:

You'll note the use of the derived table in the subselect. This is terrible, in my opinion. Only advanced SQL programmers know how to write this (I’ve often asked this question in job interviews I’ve never once seen anybody get it right). And it shouldn’t be hard!

好吧，Kallen 将此归因于 SQL 中组合下缺少闭包。在某些情况下这可能是正确的，但我的经验要平淡得多——大多数开发人员在 SQL 方面都很糟糕。他们只知道最基本的东西，当他们试图用基于集合的语言寻找程序解决方案时，这些基本的东西被误用了。我不得不在我所在的一家公司与 所有 其他开发人员争论数据库在 3NF 中的好处，他们就是不明白。有才华的人(他们中的大多数人:)，但对 SQL 或数据库一无所知。

将其放入 C# 或 Ruby 或 Python 中，开发人员又高兴了。他们可以坚持过程/OO 思维并生成对他们来说看起来不错的代码。

我知道这不会给我赢得任何选票，可能恰恰相反，但这是我的观点。顺便说一句，Arel 看起来很有趣。

作为我上面的评论的补充，六个月以来，在这段时间里大量使用 Sequel 库，我可以说它确实是一个美丽的东西，现在我觉得我会用它领先于直接使用 SQL。它不仅非常强大，而且允许我做简单和高级的事情而无需太多头疼(总会有一些)它可以输出它使用过的 SQL，如果我觉得我需要。

这不会以任何方式否定我对大多数开发人员对 SQL 的理解的评论，(我最近被一位与其他人交谈的开发人员告诉我，规范化是存储空间昂贵的时代的遗物...... . oh dear!) 只是 Sequel 库的开发显然是由那些真正了解数据库的人完成的。如果您了解 SQL 和数据库设计等，那么它会更快地为您提供更多功能。我不能说我使用的其他 ORM 相同，但也许其他人会有不同的想法。

关于ruby - 为什么要使用 SQL 构建器？ Arel 诉 Sequel 诉 T-SQL，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4961772/