数据库是否应该仅用于持久性
许多具有 3 层架构的 Web 应用程序都在应用程序服务器中完成所有处理，并使用数据库进行持久性只是为了具有数据库独立性。在为数据库支付巨额费用后，在应用程序服务器上进行包括批处理在内的所有处理而不使用数据库的功能似乎是一种浪费。我很难说服人们我们需要两全其美。
A lot of web applications having a 3 tier architecture are doing all the processing in the app server and use the database for persistence just to have database independence. After paying a huge amount for a database, doing all the processing including batch at the app server and not using the power of the database seems to be a waste. I have a difficulty in convincing people that we need to use best of both worlds.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您在 3 层架构中没有使用数据库的哪些“功能”？想必我们充分利用了 SQL 以及所有数据管理、分页、缓存、索引、查询优化和锁定功能。
我猜想争论的焦点是我们所谓的“业务逻辑”应该在哪里实现。在应用程序服务器或数据库存储过程中。
我认为将其放入应用程序服务器有两个原因：
1）。可扩展性。如果数据库太忙，则添加更多数据库引擎相对困难。跨多个数据库对数据进行分区确实很棘手。因此，请将业务逻辑拉出到应用程序服务器层。现在我们可以有许多应用程序服务器实例都执行业务逻辑。
2）。可维护性。原则上，存储过程代码可以编写良好、模块化且可重用。实际上，用 OO 语言（例如 C# 或 Java）编写可维护的代码似乎要容易得多。由于某种原因，存储过程中的重用似乎是通过剪切和粘贴进行的，因此随着时间的推移，业务逻辑变得难以维护。我承认，有了纪律，这种情况就不会发生，但目前纪律似乎很短缺。
我们确实需要小心地真正充分利用数据库查询功能，例如避免将大量数据拉到应用程序服务器层。
What "power" of the database are you not using in a 3-tier archiecture? Presumably we exploit SQL to the full, and all the data management, paging, caching, indexing, query optimisation and locking capabilities.
I'd guess that the argument is where what we might call "business logic" should be implemented. In the app server or in database stored procedure.
I see two reasons for putting it in the app server:
1). Scalability. It's comparatively hard to add more datbase engines if the DB gets too busy. Partitioning data across multiple databases is really tricky. So instead pull the business logic out to the app server tier. Now we can have many app server instances all doing business logic.
2). Maintainability. In principle, Stored Procedure code can be well-written, modularised and resuable. In practice it seems much easier to write maintainable code in an OO language such as C# or Java. For some reason re-use in Stored Procedures seems to happen by cut and paste, and so over time the business logic becomes hard to maintain. I would concede that with discipline this need not happen, but discipline seems to be in short supply right now.
We do need to be careful to truly exploit the database query capabilities to the full, for example avoiding pulling large amounts of data across to the app server tier.
这取决于您的应用程序。您应该进行一些设置，以便您的数据库能够完成数据库所擅长的事情。您不希望在应用程序层中处理跨越数千万条记录的八表连接。对数百万行执行聚合操作也不能发出少量摘要信息。
另一方面，如果您只是执行大量 CRUD，那么将昂贵的大型数据库视为哑存储库并不会造成太大损失。但是，适合以应用程序为中心的“处理”的简单数据模型有时最终会导致您陷入不可预见的低效率。设计结。您发现自己在应用程序层处理记录集。以开始近似 SQL 连接的方式查找内容。最终，您痛苦地将这些东西重构回数据库层，在那里它们的运行效率提高了几个数量级……
所以，这取决于情况。
It depends on your application. You should set things up so your database does things databases are good for. An eight-table join across tens of millions of records is not something you're going to want to handle in your application tier. Nor is performing aggregate operations on millions of rows to emit little pieces of summary information.
On the other hand, if you're just doing a lot of CRUD, you're not losing much by treating that large expensive database as a dumb repository. But simple data models that lend themselves to application-focused "processing" sometimes end up leading you down the road to creeping unforeseen inefficiencies. Design knots. You find yourself processing recordsets in the application tier. Looking things up in ways that begin to approximate SQL joins. Eventually you painfully refactor these things back to the database tier where they run orders of magnitude more efficiently...
So, it depends.
不。它们也应该用于业务规则执行。
遗憾的是，DBMS 巨头要么能力不够，要么不愿意支持这一点，从而使这一理想成为不可能，并让他们的客户受制于他们的主要摇钱树。
No. They should be used for business rules enforcement as well.
Alas the DBMS big dogs are either not competent enough or not willing to support this, making this ideal impossible, and keeping their customers hostage to their major cash cows.
我见过一个应用程序（由一个非常聪明的人）设计的表格如下：
在应用程序中访问该表格很容易：有一些方法可以加载一个（或一组）对象，并根据需要对其进行反序列化。还有一些方法可以将对象序列化到数据库中。
但是正如预期的那样（但遗憾的是事后看来），在很多情况下我们希望在该应用程序之外以某种方式查询数据库！有多种方法可以解决这个问题：应用程序中的临时查询界面（它添加了几个间接层来获取数据）；重用应用程序代码的某些部分；手写的反序列化代码（有时用其他语言）；并且只需删除反序列化块中的任何字段即可。
我可以很容易地想象几乎所有应用程序都会发生同样的事情：能够访问您的数据只是方便。因此，我认为我非常反对将序列化数据存储在真实的数据库中 - 可能存在例外情况，即节省的成本超过了复杂性的增加（例如存储 32 位整数数组）。
I've seen one application designed (by a pretty smart guy) with tables of the form:
Access to that in the application is easy: there are methods that will load one (or a set) of objects, deserialising it as necessary. And there are methods that will serialise an object into the database.
But as expected (but only in hindsight, sadly), there are so many cases where we want to query the DB in some way outside that application! This is worked around is various ways: an ad-hoc query interface in the app (which adds several layers of indirection to getting the data); reuse of some parts of the app code; hand-written deserialisation code (sometimes in other languages); and simply having to do without any fields that are in the deserialised chunk.
I can readily imagine the same thing occurring for almost any app: it's just handy to be able to access your data. Consequently I think I'd be pretty averse to storing serialised data in a real DB -- with possible exceptions where the saving outweighs the increase in complexity (an example being storing an array of 32-bit ints).