Database 我应该在哪里访问我的数据库

我很好奇你将如何处理以下数据库访问

我们建议您有一台计算机，作为服务器工作的一部分承载您的数据库，多台客户端PC上有一些客户端软件，需要从该数据库获取信息

好吧，有两种方法可以做到这一点

每个客户端软件都直接连接到数据库

每个客户端软件都连接到服务器端软件，服务器端软件作为某种数据访问层连接到数据库

所以我想知道的是： 每种解决方案的优点和缺点是什么？

---

还有其他解决方案可能“更好”完成这项工作

您所描述的听起来像两种不同的解决方案。 第一个点与两层匹配，第二个点可以是三层

好吧，有两种方法可以做到这一点

您可以将应用程序划分为多个物理层，因此，您会发现比上面描述的更适合此体系结构（n层）的情况

每种解决方案的优点和缺点是什么

通常，将应用程序分层的动机是为了实现某种非功能性需求（可维护性、可用性、安全性等），问题在于，当您添加额外的层时，也会增加复杂性，e、 g:你的应用程序组件需要相互通信，当它们分布在多台机器上时，这就更加困难了

还有其他的解决方案，它们可能“更好”地完成这项工作

---

我不确定这里的“工作”是什么意思，但请注意，您不需要添加额外的层来访问数据库。如果您在一些机器上安装了桌面应用程序，那么一个经典的客户机/服务器（两层）模型就足够了。但是，基于web的应用程序需要一个额外的层来与浏览器交互。在这种情况下，数据库访问不是添加这一额外层的动机。

我肯定会支持第2条建议。没有代理，任何客户端应用程序都不应与数据存储对话，即：

ClientApp->WebApi->DatabaseBroker.class->MySQL

当您分离关注点并定义数据存储的有组织吞吐量时，这是一种合理的方法

一些好处是：

将客户机与数据库分离

您可以将所有客户端的所有升级、添加和操作集中在一个位置（DatabaseBroker.class）

它是非常可伸缩的

它在业务逻辑方面是安全的

用这个外行的例子来想一想：

---

海军陆战队不允许携带自己的武器作战（客户端应用程序直接与DB对话）。相反，他们从武器库（API）检查武器。军械库可以控制所有武器、维修和升级（来自数据库的数据），并确定谁可以获得什么。

mhh目前，我使用直接连接到服务器上的数据库。所以我想最好不要直接从我的程序中访问数据库