数据库责任

通常,不将业务逻辑放在数据库中被认为是一种良好的实践。主要原因是可维护性。仍然可以使用存储过程,但是在这些存储过程中包含业务逻辑会使应用程序更难调试和更新。

在数据库中包含业务逻辑还可以有效地将您与使用那个DBMS联系起来,并且不允许数据层独立于您的应用程序。例如,一旦应用程序处于活动状态,您可能会在一个数据库中遇到性能和可伸缩性问题,但是由于业务逻辑分散在整个数据库中,迁移到更可伸缩的数据库最多会耗费时间。

如果业务逻辑保存在应用程序代码(例如Java或C语言)中,并且数据层使用数据抽象层抽象,并且ORM如果语言允许,那么交换数据库就不那么麻烦了。

我们应该努力 separation of concerns 将业务逻辑置于数据库之外有助于实现这一点。

编辑:还存在性能问题,这可能意味着存储过程是保存业务逻辑的好地方。在某些情况下,在数据层(即存储过程)中包含逻辑可以减少数据抽象层和数据库之间的多次往返,从而提高性能。因为这个原因,我以前在这样的系统上工作过,但我总是发现很难维护。问题在于,您可以通过类和过程查看业务逻辑,并认为这就是它,您将看不到特定的bug或过程是如何发生的,然后您将找到存储过程并查看业务操作的另一半(当存储过程是1000行时,这是一个真正的痛点!)

与许多事情一样,您将业务逻辑放在哪里取决于您试图解决的特定问题。

数据库的真正职责是什么?

数据库的核心是存储和检索数据的系统。磁盘上的csv文件+合适的工具(如excel)就是一个简单的例子。此外,数据库还可以提供其他功能,如事务控制、数据完整性和安全性。

我们应该向de-database添加存储过程和函数,还是让它成为一个没有逻辑的数据存储库?

您想从数据库中得到什么?如果你只想要一个“位桶”,那么无论如何,把它存储在磁盘上的一个普通文件中,并称之为“数据库”。如果你想要的不止这些,那就使用适合你需要的产品。如果您想使用类似SQL的4GL查询它,请使用MySQL。如果需要事务控制、安全性、高级查询功能等,请使用其他DBMS(如果合适)。不管你选择什么产品, 利用那个产品 . 否则你就是在浪费时间和金钱。当然,你永远不会使用所有的功能(只有一个子集对你有用),但是如果你很少使用它们,你也可以降级到一个更简单的产品。

如果您使用的是Oracle,那么您可以将过程和函数(甚至更好的是,整个包)存储在数据库中的数据旁边。真正的问题是,您需要在这些过程和功能中编写什么——业务逻辑或表示逻辑?

就个人而言,我通常更喜欢让业务逻辑靠近数据,而表示逻辑是为每个接口定制的。

可以在您的数据上创建一个API层,这样无论您的应用程序如何访问您的数据库,它们都可以获得一致的数据库视图,并且都可以使用一致的机制对其进行修改。换句话说,不是多次(每个接口一次)编写业务逻辑,而是只编写一次,然后在任何地方重复使用。

我听说过为什么业务逻辑不应该存储在数据库中有两个原因:

1。可维护性:很难改变。 我从来没有真正理解过这个。打字有多难 CREATE OR REPLACE PACKAGE ?我怀疑这只是学习“另一种语言”的负担。

2。数据库独立性:在Oracle中工作的东西在其他地方不工作。 这是个大问题,而且 better minds than I 有 written about 这一个。基本上,如果你真的需要它是“数据库不可知论者”,你将不能使用你购买的数据库的任何高级功能,所以你也可以使用你能找到的最简单/最便宜的功能;在这种情况下,你不需要它在每一个数据库上工作!

我们周围有很多数据,对我们很有用。有序的信息收集有助于企业做出更正确的决策。数据库是信息的有序存储。

责任:在一个常见的场景中,我们可以说周围有很多信息,有序的信息收集称为数据,这些信息与一个实体相关,有序的数据收集称为数据库,信息与一组实体相关。这些数据库的集合是一个DBMS。数据库的职责是组织信息。

存储过程、函数更像是收集所需数据所需的业务流程。

第一个起点,

开始: 在PostgreSQL、MySQL、SQL Server(Express Edition)中选择数据库并安装。 了解有关 Codd Rules , Normal forms , Good resource 开始学习SQL,编写查询。 了解模式创建所涉及的基础知识。 学习数据库中的过程语言实现。 因此提出疑问。