我从数据库开始。我一直在玩MySQL和Informix，但从未有过现实生活中的项目。
数据库的真正责任是什么？我们应该将存储过程和函数添加到数据库中，还是只让它成为没有逻辑的数据存储库？
答案 0 :(得分：10)
数据库的真正责任是什么？
数据库的核心是存储和检索数据的系统。磁盘上的CSV文件+合适的工具（例如Excel）就是一个简单的例子。此外，数据库可能提供其他功能，例如事务控制，数据完整性和安全性。
我们应该将存储过程和函数添加到数据库中，还是只让它成为没有逻辑的数据存储库？
您想从数据库中得到什么？如果你想要的只是一个“位桶”，那么无论如何，将它存储在磁盘上的普通文件中并将其称为“数据库”。如果您想要更多，请使用适合您需求的产品。如果您希望能够使用类似SQL的4GL查询它，请使用MySQL。如果您需要事务控制，安全性，高级查询功能等，请使用其他DBMS（如果适用）。但是，无论您选择哪种产品，都会利用该产品。否则你会浪费你的时间和金钱。当然，你永远不会使用所有的功能（只有一个子集对你有用），但如果你使用的很少，你也可以降级为更简单的产品。
如果您使用的是Oracle，则可以将数据库中的过程和函数（甚至更好的整个软件包）存储在数据库中。真正的问题是，您需要在这些程序和功能中编写什么 - 业务逻辑或表示逻辑？
就个人而言，我通常更喜欢将业务逻辑保持在数据附近，而为每个接口定制表示逻辑。
可以在数据上创建一个API层，这样无论您的应用程序如何访问您的数据库，它们都会获得一致的视图，并且它们都将使用一致的机制对其进行修改。换句话说，不是多次编写业务逻辑（每个接口一次），而是只编写一次，然后在任何地方重复使用。
我听说有两个原因导致业务逻辑不应存储在数据库中：
<强> 1。可维护性：很难改变。我从来没有真正理解这一点。输入CREATE OR REPLACE PACKAGE有多难？我怀疑这只是学习“另一种语言”的负担。
<强> 2。数据库独立性：在Oracle中有效的方法在其他地方不起作用。这是一个大问题，better minds than I有written about这个。基本上，如果你真的需要它是“数据库不可知”，你将无法使用你购买的数据库的任何高级功能，所以你也可以使用你能找到的最简单/最便宜的功能;在这种情况下，你无论如何都不需要它在每个数据库上工作！
答案 1 :(得分：4)
通常，不将业务逻辑放在数据库中是一种很好的做法。主要原因是可维护性。可以使用存储过程，但在这些存储过程中包含业务逻辑会使您的应用程序更难调试和更新。
在数据库中包含业务逻辑也将有效地将您绑定到使用该DBMS，并且不允许数据层保持独立于您的应用程序。例如，一旦您的应用程序处于活动状态，您可能会遇到一个数据库的性能和可伸缩性问题，但由于业务逻辑分布在整个数据库中，迁移到更具可扩展性的数据库将是最耗时的。
如果业务逻辑保存在应用程序代码中（例如java或c＃），并且使用数据抽象层抽象数据层，并且如果语言允许则抽象ORM，那么交换数据库的问题就少得多。
我们应该努力separation of concerns，并且将业务逻辑保持在数据库之外有助于实现这一目标。
编辑：还有一些性能问题可能会导致存储过程是保持业务逻辑的好地方。在某些情况下，在数据层（即sproc）中包含逻辑会减少数据抽象层和数据库之间的许多往返，这可以提高性能。因为这个原因，我过去曾经在这样的系统上工作，但我总是觉得很难维护。问题在于，您可以查看类和过程以查看业务逻辑并认为是它并且您将无法看到特定错误或进程如何发生，然后您将找到存储过程并查看另一半业务操作（当sproc为1000行时真正的痛苦！）
与许多事情一样，您放置业务逻辑的位置取决于您尝试解决的特定问题。
答案 2 :(得分：1)
我们周围有很多数据对我们很有用。有序的信息收集有助于企业做出更正确的决策。数据库是有序的信息存储。
责任：在一个常见的场景中，我们可以说周围有很多信息，有序的信息收集被称为数据，这个信息与一个实体有关，而有序的数据收集是一个数据库，有关的信息是实体组。这些数据库的集合是DBMS。数据库的责任在于组织信息。存储过程，功能更像是您收集所需数据所需的业务流程。
第一个起点，
BEGIN： 在{postgreSQL，MySQL，SQL Server（Express Edition）}中选择数据库并安装它。 了解Codd Rules，Normal forms，Good resource 开始学习SQL，编写查询。 了解架构创建中涉及的基础知识。 学习数据库中的过程语言实现。 在SO中提出质疑。