我有一个用 Ruby 编写的中型应用程序，它大量使用了 RDBMS。随着代码的增长，我发现丑陋的 SQL 语句正在蔓延到我的应用程序中的所有模块和方法，并嵌入到许多应用程序逻辑中。我不确定这是否不好，但是，我的直觉告诉我这很丑……
所以通常在任何语言中，你如何管理你的 SQL 语句？或者您认为让许多 SQL 语句嵌入应用程序逻辑中对可维护性有害吗？为什么或者为什么不？
谢谢。
user2139538
问问题
86 次
5 回答
2
SQL 是一种用于访问数据库的语言。通常，它会被误认为是大型应用程序的数据存储中的 API。事实上，您应该在数据存储和应用程序之间设计一个真正的 API。
这意味着几件事。
要访问存储在表中的数据，您希望通过数据库中的视图，而不是直接访问表。
对于数据修改步骤，您希望将insert//包装在存储过程中。这有第二个好处，您可以在存储过程中处理约束和触发器，并更好地记录正在发生的事情。updatedelete
出于安全考虑，您希望将数据库安全性作为安全架构的一部分。授予所有用户完全访问权限可能不是最好的方法。
不幸的是，编写一个直接使用数据库的简单应用程序很容易，无论是在 java 还是 ruby 或 VBA 中或其他任何语言中。这成长为一个更大的应用程序，然后出现维护问题。
我建议采用增量方法来解决此问题。浏览代码并在您有讨厌的选择语句的地方创建视图。您可能会发现您需要的视图比选择的视图少得多（视图可以重复使用——这是一件好事）。
查找代码被修改的地方，并将它们更改为存储过程。我总是从存储过程中返回状态以进行错误检查，并将日志信息放入一个名为 someting like splogor的表中_spcalls。
如果您想限制应用程序的不同用户的权限，那么您可能对此感兴趣。
将原始 SQL 语句留在代码中是一个问题。等到你想重命名一个列，你必须找到所有破坏代码的地方。
于 2013-03-27T17:49:10.433 回答
0
是的，这不是最优的——维护变成了一场噩梦；当基础数据库更改发生时，很难预测和确定哪些代码必须更改。这就是为什么创建数据访问层 (DAL) 以封装来自应用程序逻辑的 CRUD 操作的良好做法的原因。在应用程序逻辑和 DAL 之间通常有一个业务逻辑层 (BLL) 来执行业务规则/逻辑。
谷歌“数据访问层”“业务逻辑层”甚至“n 层架构”了解更多。
于 2013-03-27T17:22:00.073 回答
0
如果您担心散布在应用程序逻辑周围的 SQL 语句，是否可以考虑将它们实现为存储过程？
这样，您将只在代码中包含过程名称和需要传递给它的任何参数。
它还有其他好处，一个常见的好处是更容易在多个文件中重复使用。
关于存储过程的速度和安全性有很多争论，你永远不会得到一个明确的答案，所以我什至不会打开那个蠕虫罐头。
于 2013-03-27T17:22:05.987 回答
0
下面是使用 Java 执行此操作的方法： 创建一个封装对数据库的所有访问的类。为您需要运行的每个查询添加一个方法到类。
ruby 的答案将与此类似。
于 2013-03-27T17:28:32.813 回答
0
这取决于应用程序的体系结构，但一个简单的解决方案是将每个 sql 保存在一个文件 qry.sql 中。对于每个 Ruby 模块（或 Ruby 中用于聚合相关代码的任何模块），您可以将这些文件保存在 SQL 文件夹中。因此，SQL 文件夹/文件的集合构成了应用程序的数据访问层。Ruby 代码提供了业务层。如果您的数据模型发生更改（字段名称等），您可以执行 greps 来识别需要更改的 sql 文件。无论如何，绝对将 SQL 与您的逻辑代码分开。
于 2013-03-27T17:52:39.870 回答