单个或多个数据库答案

【问题标题】：Single or multiple databases单个或多个数据库
【发布时间】：2009-11-04 20:55:49
【问题描述】：

SQL Server 2008 数据库设计问题。

我正在为一项服务定义架构，在该架构中，站点用户将管理他们拥有的多个网站上的大量数据（平均 100MB，每个站点最大 1GB）。我正在考虑是否拆分数据库，以便将核心站点管理表（用户、付款、联系方式、登录详细信息、产品等）保存在一个数据库中，而与客户自己的网站相关的数据库保存在一个单独的数据库中数据库。

我看到了一个可能的收获，因为我可以分配硬件架构，从而为网站数据库中完成的繁重工作提供更多内容，从而将网站管理数据库留在更合适的区域。但我也意识到失去了通过外键直接将网站与客户相关联的能力（据我所知，这不能跨数据库完成？）。

所以，问题有两个方面 - 一般而言，这种情况下的数据应该被拆分到多个数据库中，还是应该全部保存在一个数据库中？

如果拆分成多个，有没有推荐的方法在数据库层保护系统的完整性和安全性，保证两者之间存在强关系？

感谢您的帮助。

【问题讨论】：

标签： sql sql-server database sql-server-2008 database-design

【解决方案1】：

这个问题和我的回答可能接近于主观的灰色线，但至少我认为将“管理员”表分离到他们自己的数据库中是一种常见的做法，听起来像你正在做。如果您可以将客户端绑定到特定的服务器和数据库实例，那么通过拥有单独的数据库实例，它为添加服务器以添加客户端开辟了一些简单的路径。如果您的数据库太大，单个数据库将需要您使用各种集群方法。

[edit]尽早建立每个客户都拥有自己的数据库的想法，这也只是为您在易于进行结构和组织更改时的开发方式定下了基调。发现 2 年后你需要这样做会变得更加痛苦。我过去曾多次使用 split dbs，只要您能确定上下文是什么，它真的不难处理。在这里，您似乎已经知道客户端就是上下文。

就我的两分钱，就像我说的，你在这方面可能接近主观。

【讨论】：

感谢 Jim - 集群并不是我真正想做的事情（它在我的日常工作中一直困扰着我），这让我更加朝着分裂的方向前进。
Re: 编辑 - 如果这成功了，我肯定希望在未来避免太多的悲伤 - 我想我会分开的。
集群不适用于跨多台服务器的查询。

【解决方案2】：

单数据库专家

要维护一个数据库。一个数据库来统治他们，在黑暗中 - 绑定他们......
一个连接字符串
可以使用Clustering

每个客户专业人士的单独数据库

支持基于每个客户的定制
安全性：客户不可能看到彼此的数据

结论

如果您计划支持每个客户的定制，那么单独的数据库方法将是有效的。否则我看不到价值。

【讨论】：

【解决方案3】：

您可以使用链接来连接数据库。你的架构很聪明。

如果您无法使用链接，您始终可以以只读模式将关键数据从用户数据库复制到网站数据库。

关于安全性 - 最好的方法是在 ASP（或其他网络语言）和数据库之间建立一个服务层 - 这样您的数据库就会非常独立。

【讨论】：

谢谢 Dani - 你能确认你所说的“链接”是什么意思吗 - 在我简单地在另一个数据库中记录适当的密钥然后在软件中引用之前，我有这样的相互关联的数据库。至少可以说是一件令人头疼的事情，并且担心疏忽和错误披露不是这个应用程序的选项。应用层是 ASP.NET 3.5。再次感谢。
这是一篇文章，其中包含简单的链接示例，以通过c-sharpcorner.com/UploadFile/john_charles/…了解想法

【解决方案4】：

如果您希望将来由于负载过重而不得不将数据库拆分到不同的硬件上，我会说现在拆分它。您可以使用复制将某些表的副本从主数据库推送到站点管理数据库。目前，您可以在同一个 SQL Server 实例上运行这两个数据库，稍后，当您需要时，您可以随着容量的增长将一些数据库移动到单独的机器上。

【讨论】：

【解决方案5】：

想象我们有无限快的计算机，你会拆分你的数据库吗？当然不是。我们拆分它们的唯一原因是为了方便我们在某个时候向外扩展。您在这里别无选择，每个客户端 100MB-1000MB 是巨大的。

【讨论】：