数据库是否应该仅用于持久性答案

【问题标题】：Should Databases be used just for persistence数据库是否应该仅用于持久性
【发布时间】：2011-02-26 15:50:08
【问题描述】：

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

【问题讨论】：

标签： database web-applications three-tier

【解决方案1】：

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

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

所以，这取决于。

【讨论】：

【解决方案2】：

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

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

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

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

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

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

【讨论】：

+1 关于 SP 的通常较弱的工作流程的要点。很少有不是这样的。

【解决方案3】：

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

id | one or two other indexed columns | big_chunk_of_serialised_data

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

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

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

【讨论】：

感受到那种痛苦。对程序员更好，但不一定是程序。不可避免地，业务需求突然变成了一个实时仪表板，显示每个序列化 blob 中有多少个序列化 blob。

【解决方案4】：

没有。它们也应该用于执行业务规则。

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

【讨论】：