database - 数据库是否应该仅用于持久性

Question

许多具有 3 层架构的 Web 应用程序都在应用程序服务器中进行所有处理，并使用数据库进行持久性，只是为了具有数据库独立性。在为数据库支付了巨额费用之后，在应用服务器上进行包括批处理在内的所有处理而不使用数据库的功能似乎是一种浪费。我很难说服人们我们需要两全其美。

Answer 1

您没有在 3 层架构中使用数据库的哪些“功能”？大概我们充分利用了 SQL，以及所有的数据管理、分页、缓存、索引、查询优化和锁定功能。

我猜想这个论点是应该实现我们所谓的“业务逻辑”的地方。在应用服务器或数据库存储过程中。

我看到将其放入应用服务器的两个原因：

1）。可扩展性。如果数据库太忙，添加更多数据库引擎相对困难。跨多个数据库对数据进行分区非常棘手。因此，改为将业务逻辑拉到应用服务器层。现在我们可以有很多应用服务器实例都在做业务逻辑。

2）。可维护性。原则上，存储过程代码可以编写良好、模块化和可重复使用。在实践中，用 C# 或 Java 等 OO 语言编写可维护的代码似乎要容易得多。由于某种原因，存储过程中的重用似乎是通过剪切和粘贴来实现的，因此随着时间的推移，业务逻辑变得难以维护。我承认，有了纪律，这不一定会发生，但现在纪律似乎供不应求。

我们确实需要小心地真正充分利用数据库查询功能，例如避免将大量数据拉到应用服务器层。

Answer 2

这取决于您的应用程序。您应该进行设置，以便您的数据库执行数据库适合的操作。跨越数千万条记录的八表连接不是您想要在应用程序层中处理的事情。对数百万行执行聚合操作也不会发出少量摘要信息。

另一方面，如果你只是在做大量的 CRUD，那么将那个昂贵的大型数据库视为一个愚蠢的存储库，你并不会损失太多。但适用于以应用程序为中心的“处理”的简单数据模型有时最终会导致您走上无法预见的低效率之路。设计结。您会发现自己在应用层处理记录集。以开始近似 SQL 连接的方式查找内容。最终，您痛苦地将这些东西重构回数据库层，在那里它们可以更有效地运行几个数量级......

所以，这取决于。

Answer 3

我见过一个应用程序（由一个非常聪明的人设计），其表格如下：

id | one or two other indexed columns | big_chunk_of_serialised_data

在应用程序中访问它很容易：有一些方法可以加载一个（或一组）对象，并在必要时对其进行反序列化。还有一些方法可以将对象序列化到数据库中。

但正如预期的那样（但遗憾的是，只是事后看来），在很多情况下，我们想在应用程序之外以某种方式查询数据库！可以通过多种方式解决此问题：应用程序中的临时查询接口（它增加了几层间接获取数据）；重用应用程序代码的某些部分；手写反序列化代码（有时用其他语言）；并且只需不需要反序列化块中的任何字段即可。

我可以轻松想象几乎所有应用程序都会发生同样的事情：能够访问您的数据非常方便。因此，我认为我非常反对将序列化数据存储在真正的数据库中——除了节省超过复杂性增加的可能例外（例如存储 32 位整数数组）。

Answer 4

不，它们也应该用于业务规则执行。

唉，DBMS 大狗要么没有足够的能力，要么不愿意支持这一点，这使得这个理想变得不可能，并让他们的客户成为他们主要摇钱树的人质。