许多具有3层体系结构的Web应用程序正在应用程序服务器中执行所有处理，并使用数据库进行持久化以使数据库独立。在为数据库支付了大笔费用之后，在应用服务器上进行所有处理（包括批处理而不使用数据库的功能）似乎是一种浪费。我难以说服人们我们需要充分利用两个世界。
答案 0 :(得分：3)
您在3层架构中没有使用数据库的“权力”？据推测，我们充分利用SQL，以及所有数据管理，分页，缓存，索引，查询优化和锁定功能。
我猜这个论点是应该实现我们所谓的“业务逻辑”的地方。在app服务器或数据库存储过程中。
我认为将其放入应用服务器有两个原因：
1）。可扩展性。如果数据库太忙，添加更多数据库引擎相对比较困难。跨多个数据库分区数据非常棘手。因此，将业务逻辑拉出到应用服务器层。现在我们可以让许多app服务器实例都做业务逻辑。
2）。可维护性。原则上，存储过程代码可以很好地编写，模块化和可恢复。实际上，用C＃或Java等OO语言编写可维护代码似乎要容易得多。出于某种原因，存储过程中的重复使用似乎是通过剪切和粘贴进行的，因此随着时间的推移，业务逻辑变得难以维护。我承认，有了纪律，这种情况不需要发生，但现在纪律似乎供不应求。
我们需要小心真正充分利用数据库查询功能，例如避免将大量数据传输到应用服务器层。
答案 1 :(得分：2)
这取决于您的申请。你应该进行设置，这样你的数据库就能完成数据库的优点。跨越数千万条记录的八表连接并不是您希望在应用程序层中处理的内容。也没有对数百万行执行聚合操作以发送少量摘要信息。
另一方面，如果你只是做了很多CRUD，那么将这个庞大的昂贵数据库视为一个愚蠢的存储库，你就不会失去太多。但是，简单的数据模型有助于以应用为中心的“处理”，有时最终导致您无法预料到无法预料的低效率。设计结。您发现自己在应用程序层中处理记录集。以开始近似SQL连接的方式查找内容。最终，你痛苦地将这些东西重构回数据库层，在那里它们可以更有效地运行数量级......
所以，这取决于。
答案 2 :(得分：0)
我见过一个应用程序（由一个非常聪明的人）设计的表格：
id | one or two other indexed columns | big_chunk_of_serialised_data
在应用程序中访问它很容易：有些方法可以加载一个（或一组）对象，并根据需要对其进行反序列化。并且有一些方法可以将对象序列化到数据库中。
但是正如预期的那样（但遗憾的是，事后看来），有很多情况我们想要以某种方式在该应用程序之外查询数据库！这可以通过各种方式解决：应用程序中的临时查询接口（它可以为获取数据添加多个间接层）;重用应用程序代码的某些部分;手写的反序列化代码（有时用其他语言）;并且只需要没有反序列化块中的任何字段。
我很容易想象几乎任何应用程序都会发生同样的事情：它只是方便才能访问您的数据。因此，我认为我非常反对将序列化数据存储在真实数据库中 - 可能的例外情况是保存超过复杂性的增加（例如存储32位整数数组）。
答案 3 :(得分：0)
没有。它们也应该用于执行业务规则。
唉，DBMS的大狗要么不够称职，要么不愿意支持这一点，这使得这个理想不可能，并且让他们的客户成为他们主要的现金奶牛。