关于将代码放置在何处：将代码放置在何处-数据库与应用程序？

Where to put your code - Database vs. Application?

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

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

您认为余额在哪里？

谢谢，
克鲁纳尔

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

其他所有内容都应纳入代码中。

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

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

这是不可调试的

不受源代码控制

两组代码的权限将有所不同

如果您要从两个地方访问数据库中的信息，将更加难以跟踪数据中错误的出处

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

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

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

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

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

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

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

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

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

阅读这些答案，我对数据库编程缺乏了解感到困惑。我是Oracle Pl / sql开发人员，我们为进入数据库的每一段代码提供源代码控制。许多IDE为大多数主要的源代码控制产品提供插件。从ClearCase到SourceSafe。我们使用的Oracle工具允许我们调试代码，因此调试不是问题。问题更多是逻辑和可访问性。

作为大约5000个用户的支持经理，我寻找逻辑的地方越少越好。如果我想确保逻辑适用于所有使用数据的应用程序，甚至是业务逻辑，我都将其放入数据库中。如果逻辑因应用程序而异，则可以对此负责。

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

@DannySmurf：

这是不可调试的

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

不受源代码控制

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

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

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

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

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

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

您的数据库不是很好(请考虑一下SQL Server如何不实现LIMIT，并且您必须使用过程来解决该问题。

您希望能够通过仅更改一个地方的代码来更改行为，而无需重新部署客户端应用程序。

客户端计算机具有很大的计算能力约束(请考虑使用小型嵌入式设备)。

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