architecture - 客户端到DB与客户端到服务器到DB

我必须选择创建新应用程序的方式：Client-DataBase（具有在存储过程中实现的业务逻辑）或Client-Server-DataBase（其中业务逻辑在服务器端实现，使存储过程仅具有数据表示函数）。

今天存在存储过程，允许创建非常智能的DB，并且参数＆＃34;客户端不应该具有业务逻辑＆＃34;不好：对于存储过程，它可能没有太多的业务逻辑。我该怎么创建服务器？或者我不需要它并且应该尝试在存储过程方面尽可能地实现最大值？

如果我需要联系许多数据库，可以通过异步连接与服务器联系。使用DB变体，我可以使用dblinks（甚至也是async，据我所知）。

是偏好问题，还是存在我尚未看到的架构需求和逻辑？

大多数现代应用程序使其数据库尽可能愚蠢。将逻辑踢出它们使应用程序更具可扩展性，可测试性和可移植性。

将业务逻辑放入存储过程意味着您必须通过制作越来越大的数据库来垂直扩展应用程序。

与测试独立的业务逻辑层相比，测试存储过程非常困难和昂贵。

它还将您与一个数据库提供商紧密联系在一起。

如果这些都不是问题，那么将所有逻辑放入存储过程可能是一个可行的解决方案。我从来没有见过基于存储过程的应用程序并不是一团糟。我并不是说它们天生就是邪恶的，但我几乎总是看到它们被滥用，而且由此产生的泥球应用通常是废话和重写的事情。

无论如何，做一些阅读：