我已经开发Web /桌面应用程序已有大约6年了。在我的职业生涯中，我遇到了使用存储过程大量写在数据库中的应用程序，而对于每个实体，很多应用程序只有几个基本存储过程(以读取，插入，编辑和删除实体记录) 。

我见过有人争辩说，如果我们为企业数据库付费，则可以广泛使用其功能。鉴于许多"面向对象的架构师"告诉我，将多余的东西放在数据库中绝对是犯罪行为，那么我们应该能够使用这些类上的方法来驱动应用程序？

我们认为余额在哪里？

谢谢，
克鲁纳尔

解决方案

回答

我在面向对象的架构师营中。只要我们了解随之而来的警告，将代码放入数据库中并不一定构成犯罪。这里有一些：

• 这是不可调试的
• 不受源代码控制
• 两组代码的权限将有所不同
• 如果我们要从两个地方访问数据库中的信息，将更加难以跟踪数据中错误的出处

回答

我认为这是业务逻辑与数据逻辑的关系。如果存在确保数据一致性的逻辑，则将其放入存储过程中。与便利功能相同，用于数据检索/更新。

其他所有内容都应包含在代码中。

我的一个朋友正在开发一系列存储过程，用于生物信息学中的数据分析算法。我认为他的方法很有趣，但从长远来看不是正确的方法。我的主要反对意见是可维护性和缺乏适应性。

回答

我来自几乎相同的背景，并且听过相同的论点。我确实了解将逻辑放入数据库的确有充分理由。但是，这取决于应用程序的类型以及处理数据的方式，应该选择哪种方法。

以我的经验，使用ORM层将使诸如某些客户(或者xyz)管理人员这样的典型数据输入应用程序从中受益匪浅，因为在数据上没有太多不同的视图，我们可以将样板CRUD代码减少到最少。

另一方面，假设应用程序具有大量并发性和计算量，这些应用程序跨越许多表，并且具有带有锁定等功能的细粒度列级安全性概念，那么我们最好做一些类似的事情直接在数据库中。

如前所述，它还取决于我们期望数据使用的各种视图。如果需要将许多不同的列和表组合呈现给用户，则最好只交出不同的结果集，而不是将对象一一映射到另一种表示。

毕竟，数据库擅长处理集合，而OO代码擅长处理单个实体。

回答

好吧，这很难。作为程序员，我们将尽可能避免使用TSQL和此类"数据库语言"，因为它们太可怕了，难以调试，无法扩展，并且我们将无法做任何事情在应用程序上使用代码。

我看到编写存储过程的唯一原因是：

• 数据库不是很好(请考虑一下SQL Server如何不实现LIMIT，并且我们必须使用一个过程来解决该问题。
• 我们希望能够通过仅更改一个地方的代码来更改行为，而无需重新部署客户端应用程序。
• 客户端计算机具有很大的计算能力约束(请考虑使用小型嵌入式设备)。

但是对于大多数应用程序，我们应该尝试将代码保留在可以调试的应用程序中，将其置于版本控制下，并使用语言提供的所有工具对其进行修复。

回答

@DannySmurf：

这是不可调试的

是的，取决于服务器，它们是可调试的。这提供了SQL Server 2000的示例。我猜较新的版本也有此示例。但是，据我所知，免费的MySQL服务器没有此功能。

不受源代码控制

是的。有点儿。数据库备份应包括存储过程。这些备份文件可能会或者可能不在版本控制存储库中。但是无论哪种方式，我们都可以备份存储过程。

回答

我个人的喜好是尝试将尽可能多的逻辑和配置保留在数据库之外。这些天，我严重依赖Spring和Hibernate，这使它变得容易得多。我倾向于在S​​pring应用程序上下文XML文件中使用Hibernate命名查询而不是存储过程和静态配置信息。任何需要进入数据库的内容都必须使用脚本加载，并且我将这些脚本保留在版本控制中。

回答

@Thomas Owens ：(是源代码控制)是的，但是从我可以检入.cs文件(或者.cpp文件或者其他文件)并选择所需的任何修订版本的意义上来说，这不是源代码控制。为此，使用数据库代码需要大量的工作量，或者从数据库中检索过程并将其转移到源树中的某个位置，或者在每次进行较小更改时进行数据库备份。无论哪种情况(无论付出多少努力)，都不是直观的。对于许多商店来说，这也不是一个很好的解决方案。对于那些可能不像其他人那么勤奋的开发人员来说，这里还有可能忘记检索和签入修订。从技术上讲，可以将任何内容置于源代码控制中。断开连接是我要解决的问题。

(可调试)足够公平，尽管它并不能与应用程序的其余部分(大多数代码可以存在的地方)提供太多集成。这可能重要，也可能不重要。

回答

与引用完整性或者一致性有关的所有内容都应至少包含在数据库中。如果它在应用程序中，并且有人想针对数据库编写应用程序，那么他们将不得不在代码中复制代码以确保数据保持一致。

PLSQL for Oracle是访问数据库的一种非常不错的语言，它还可以提高性能。应用程序也可以更加"整洁"，因为它将数据库存储过程视为"黑匣子"。

存储过程本身也可以被调整和修改，而无需我们靠近编译的应用程序，如果应用程序供应商停业或者不可用，这也很有用。

我并不是在提倡"一切"都应该放在数据库中，而不是它。将每种情况分开并在逻辑上进行处理，我们会发现哪种情况更有意义，将其放在应用程序中或者数据库中。

回答

好吧，如果我们关心数据的一致性，则有理由在数据库中实现代码。正如其他人所说，将代码(和/或者RI /约束)放置在数据库中的作用是强制执行业务逻辑，使其靠近数据本身。而且，它提供了一个通用的封装界面，因此新开发人员不会意外创建孤立记录或者不一致的数据。