与SQL:：Abstract相比，SQL:：Interp有哪些缺点（如果有的话）？

我目前正在研究一些轻量级SQL抽象模块。我的工作流程是这样的，我通常手动编写SELECT查询，并通过接受哈希的SUB插入/更新查询

这两个模块似乎都非常适合我的需要，我很难做出决定。声明不能在SQL中提供完整的表达能力，但没有讨论其他差异

---

它有什么缺点吗？如果是这样的话，哪一个？

我不能与SQL:：Interp交谈，但我使用SQL:：Abstract，它非常好。与普通的和旧的结合，我能够完全消除ORM在我的系统中的使用，并且几乎没有任何负面影响

---

我遇到的唯一限制是不可能直接编写GROUP BY查询（尽管只需将其附加到生成的查询中很容易做到，并且限制查询由扩展处理。

我使用SQL:：Abstract一年多，然后切换到SQL:：Interp，从那以后我一直使用它

Abstract在处理复杂子句时遇到了问题。对于它可以支持的那些子句，您将得到一组“（“”[”和{”字符，您在心里将这些字符翻译回“and”、“OR”或实际上是括号的意思

SQL:：Interp没有这样的限制，也不使用中间表示法。您的SQL看起来像是带有绑定变量的SQL。它既适用于简单查询，也适用于复杂查询。我发现SQL:：Interp与的内置支持结合使用特别令人愉快。DBIx:：simple+SQL:：Interp是一个友好直观的替代品t用于使用原始DBI。我在100000 k+LoC mod_perl web应用程序中使用该组合。

还有Fey模块。。。