我目前正在研究一些轻量级的SQL抽象模块。我的工作流程是这样的，我通常手动编写SELECT查询，并通过带有哈希的子进行INSERT / UPDATE查询。
这两个模块似乎都很适合我的需求，我很难决定。 SQL::Interp声明SQL::Abstract无法在SQL中提供完整的表达能力，但没有讨论其他差异。
它有任何缺点吗？如果是这样，哪个？
答案 0 :(得分：3)
我不能说SQL :: Interp，但我使用SQL :: Abstract，它非常好。与DBIx::Connector和普通的DBI结合使用，我能够完全消除在我的系统中使用ORM而且几乎没有任何缺点。
我遇到的唯一限制是不能直接编写GROUP BY查询（尽管只需附加到生成的查询就可以轻松完成，LIMIT查询由扩展名SQL::Abstract::Limit处理。 / p>
答案 1 :(得分：3)
我使用SQL :: Abstract超过一年，然后切换到SQL :: Interp，我从那时起就坚持了。
SQL :: Abstract在复杂子句中遇到了麻烦。对于它可以支持的那些，你最终会得到一个“（”“”“[”和{“字符的嵌套，你在心理上将其翻译成意义为”AND“，”OR“或实际上是括号。
SQL :: Interp没有这样的限制，也没有使用中间表示。您的SQL看起来像SQL，带有您想要的绑定变量。它适用于复杂查询以及简单查询。我发现SQL :: Interp特别适合与DBIx::Simple的内置支持结合使用。 DBIx :: Simple + SQL :: Interp是使用原始DBI的友好且直观的替代品。我在100,000k + LoC mod_perl网络应用程序中使用该组合。