如何避免SQL语句在应用程序的各处传播？

Question

我有一个用Ruby编写的中型应用程序，它大量使用RDBMS。随着代码的增长，我发现丑陋的SQL语句正在扩展到我的应用程序中的所有模块和方法，并嵌入到许多应用程序逻辑中。我不确定这是不是很糟糕，但是，我的直觉告诉我这很难看......

通常在任何语言中，您如何管理SQL语句？或者您认为在应用程序逻辑中嵌入许多SQL语句对于维护是否有害？为什么或为什么不呢？

感谢。

Answer 1

SQL是一种用于访问数据库的语言。通常，它会被混淆为将API作为更大应用程序的数据存储。实际上，您应该在数据存储和应用程序之间设计一个真正的API。

这意味着几件事。

要访问存储在表中的数据，您希望浏览数据库中的视图，而不是直接访问表。

对于数据修改步骤，您希望在存储过程中包装insert / update / delete。这具有次要优势，您可以在存储过程中处理约束和触发器，并更好地记录正在发生的事情。

为了安全起见，您希望将数据库安全性包含在安全体系结构中。为所有用户提供完全访问权限可能不是最佳方法。

不幸的是，编写一个直接使用数据库的简单应用程序很容易，无论是在java还是ruby或VBA等等。这会变成一个更大的应用程序，然后出现维护问题。

我建议采用增量方法来解决这个问题。浏览代码并创建有令人讨厌的select语句的视图。您可能会发现您需要的视图比选择的少得多（视图可以重复使用 - 这是一件好事）。

查找正在修改代码的位置，并将其更改为存储过程。我总是从存储过程返回状态以进行错误检查，并将日志信息放入一个名为splog或_spcalls的表中。

如果您想限制应用的不同用户的权限，那么您可能会对this感兴趣。

将原始SQL语句留在代码中是一个问题。只要等到你想要重命名一个列，就必须找到破坏代码的所有地方。

Answer 2

是的，这不是最佳选择 - 维护成为一场噩梦;在发生基础数据库更改时，很难预测并确定哪些代码必须更改。这就是为什么创建数据访问层（DAL）以从应用程序逻辑封装CRUD操作的好习惯。应用程序逻辑和DAL之间通常有一个业务逻辑层（BLL）来强制执行业务规则/逻辑。

谷歌“数据访问层”“业务逻辑层”甚至“n层架构”了解更多。

Answer 3

如果您担心围绕应用程序逻辑的SQL语句，可以考虑将它们作为存储过程实现吗？

这样，您只需在代码中包含过程名称和需要传递给它的任何参数。

它还有其他好处，一个常见的更容易在多个文件中重复使用。

关于存储过程的速度和安全性存在很多争论，你永远不会得到关于这一点的明确答案，所以我甚至不会打开那些蠕虫。

Answer 4

以下是使用Java执行此操作的方法：创建一个封装对数据库的所有访问权限的类。为您需要运行的每个查询添加一个方法。

红宝石的答案与此相似。

Answer 5

这取决于应用程序的体系结构，但一个简单的解决方案是将每个sql保存在文件qry.sql中。对于每个Ruby模块（或Ruby中用于聚合相关代码的任何内容），您可以使用这些文件保留文件夹SQL。因此，SQL文件夹/文件的集合构成了应用程序的数据访问层。 Ruby代码提供业务层。如果您的数据模型发生更改（字段名称等），您可以执行greps来识别需要更改的sql文件。无论如何，肯定将SQL与逻辑代码分开。