数据库结构

Question

我已经寻找了一段时间如何解决这个问题，最后我决定也许应该寻求一些帮助。

我们有两个不同的应用程序(app1和app2)，每个应用程序都有一个不同的数据库(db1和db2)。然后，我们有另一个项目使用这两个数据库来管理这些应用程序数据。这将是app3与db1和db2。

在db1中，我们有一个客户端表来设置哪个客户端具有活动的哪个应用程序。例如:客户机1具有活动app1，客户机2具有活动app1和app2，等等。这是从app3管理的。

问题是，在app2中，我们需要访问db1中的这个表，以了解用户是否激活了该应用程序来登录。

我们正在考虑在另一个数据库中分隔这个表，但是由于我们不是数据库专家，我们想知道是否还有其他更好的解决方案来解决这个问题。

将来可能会有一个具有相同客户端和不同数据库的第四应用程序，因此我们也会遇到同样的问题。复制客户这不是一种选择。

我们使用的是Server和.NET核心。

谢谢

Answer 1

如果所有数据库都位于同一个实例上，或者在它们之间设置了链接服务器，则可以在Server中跨多个数据库进行查询。登录将需要访问所有数据库。

对于您的设计问题，我认为为客户端连接提供第三个数据库是有意义的。这将使应用程序能够专注于其数据库中的特定数据需求，而客户端连接需求则只关注这一点，而不会过多地跨越域。

Answer 2

正如其他人所指出的，您可以通过跨数据库查询访问Tables、Views、Stored Procedures、Functions和大多数其他对象。因此，从这个角度来看，您不应该遇到任何问题，不管您把表放在哪里。

这可以归结为业务逻辑和管理原因，即您是否希望将该表放入其自己的数据库中。我做到了这两种方式和个人(至少对于非大数据缩放/高工作负载应用程序)，我喜欢将我的所有业务应用程序表保存在同一个数据库中，但对每个应用程序使用不同的模式。

因此，在您的上下文中，将有一个BusinessApplicationsDatabase，一个用于App1的模式，一个单独的App2模式，默认的模式dbo (或者您也可以创建自己的模式)将用于通用的表。在我看来，这样做可以更好地组织数据对象。它还允许他们访问不可用的跨数据库对象，例如用户定义的类型(这些类型是否是好的做法是另一种讨论，但作为一个例子)。它还使数据库在备份、同步或移动到其他服务器时更易于移植和管理。此外，数据库服务器内部的安全管理会稍微好一些，因为您对模式具有GRANT和DENY权限的粒度，但是您只需要将用户映射到一个数据库，而不是多个数据库。

我不想做那种设计的用例是，如果我知道一个应用程序数据将以比其他应用程序更快的速度以更大的速度增长，那么您想要分离数据库文件增长的管理。更重要的是，如果您需要使用AlwaysOn可用性组跨多个服务器复制一个应用程序的数据，那么拥有单独的数据库更好(除非数据不是很大)，因为AlwaysOn可用性组同步整个数据库。但在我看来，这些都是比较边缘的情况，而前面提到的将事物保存在同一个数据库中，但利用模式的力量的好处就不那么常见了。