我有一个用Ruby编写的中等大小的应用程序，它大量使用了RDBMS。随着我们代码的增长，我发现丑陋的SQL语句正在蔓延到我应用程序中的所有模块和方法，并嵌入到许多应用程序逻辑中。我不确定这是不是坏事，但是，我的直觉告诉我这是相当丑陋的…
一般来说，在任何语言中，你如何管理你的SQL语句?或者您认为让许多SQL语句嵌入到应用程序逻辑中对可维护性有害吗?为什么或者为什么不呢?
谢谢。
SQL是用于访问数据库的语言。通常，它会被误认为是大型应用程序的数据存储API。事实上，你应该在数据存储和应用程序之间设计一个真正的API。
这意味着几件事。
要访问存储在表中的数据，您需要遍历数据库中的视图，而不是直接访问表。
对于数据修改步骤，您需要将insert/update/delete包装在存储过程中。这还有第二个好处，您可以在存储过程中处理约束和触发器，并更好地记录正在发生的事情。
对于安全性，您希望将数据库安全性作为安全性体系结构的一部分。给所有用户完全访问权限可能不是最好的方法。
不幸的是，写一个简单的应用程序，直接使用数据库是很容易的，无论是在java或ruby或VBA或其他。当它成长为一个更大的应用程序时，维护问题就出现了。
我建议采用增量方法来解决这个问题。通读代码并在有糟糕的选择语句的地方创建视图。你可能会发现你需要的视图比选择要少得多(视图可以被重用——这是一件好事)。
查找正在修改代码的位置，并将其更改为存储过程。我总是从存储过程返回状态以进行错误检查，并将日志信息放入一个名为splog或_spcalls的表中。
如果你想限制应用程序的不同用户的权限，那么你可能会对这个感兴趣。
在代码中保留原始SQL语句是一个问题。只要等到你想重命名一个列的时候，你就必须找到所有破坏代码的地方。
是的，这不是最优的——维护变成了一场噩梦;当底层数据库发生更改时，很难预测和确定哪些代码必须更改。这就是为什么创建数据访问层(DAL)来封装来自应用程序逻辑的CRUD操作是一个很好的实践。在应用程序逻辑和DAL之间通常有一个业务逻辑层(BLL)来执行业务规则/逻辑。
谷歌"数据访问层"业务逻辑层"甚至"n层架构"了解更多。
如果您关心应用程序逻辑周围的SQL语句，也许可以考虑将它们实现为存储过程?
这样，您将只包括过程名称和需要在代码中传递给它的任何参数。
它还有其他好处，一个常见的好处是更容易在多个文件中重用。
关于存储过程的速度和安全性有很多争论，你永远不会得到一个明确的答案，所以我甚至不会打开这个棘手的问题。
如何使用Java完成此操作:创建一个类封装对数据库的所有访问。为需要运行的每个查询添加一个方法到类中。
ruby的答案与此类似
这取决于应用程序的体系结构，但一个简单的解决方案是将每个sql保存在一个文件中，即query .sql。对于每个Ruby模块(或Ruby中用于聚合相关代码的任何东西)，您可以为这些文件保留一个文件夹SQL。因此，SQL文件夹/文件的集合构成了应用程序的数据访问层。Ruby代码提供业务层。如果您的数据模型发生了变化(字段名等)，您可以执行greps来识别需要更改的sql文件。无论如何，一定要将SQL与逻辑代码分开。