SQL Server 2008数据库设计问题。
我正在定义服务的体系结构，其中网站用户可以管理他们拥有的多个网站上的大量数据（平均100MB，每个网站最多1GB）。我正在考虑是否拆分数据库，以便核心站点管理表（用户，付款，联系方式，登录详细信息，产品等）保存在一个数据库中，与客户自己的网站相关的数据库是单独保存的数据库中。
我看到了一个可能的好处，我可以分发硬件架构，为网站数据库中的繁重工作提供更多的资源，使网站管理数据库处于更合适的区域。但我也意识到失去了通过外键直接将网站与客户联系起来的能力（据我所知，这不能跨数据库完成？）。
所以，这个问题有两个问题 - 一般来说，这种情况下的数据应该分成多个数据库，还是应该都保存在一个数据库中？
如果将其拆分为多个，是否有建议的方法来保护系统在数据库层的完整性和安全性，以确保两者之间存在很强的关系？
感谢您的帮助。
答案 0 :(得分：4)
这个问题因此我的回答可能接近主观的灰线，但至少我认为通常的做法是将'admin'表分离到他们自己的数据库中，因为它听起来像你是这样做。如果您可以将客户端绑定到特定服务器和数据库实例，然后通过具有单独的数据库实例，则会为添加服务器添加客户端提供一些简单的路径。如果你太大，单个数据库会要求你使用各种聚类方法。
[edit]尽早建立每个客户获得自己的数据库的想法也只是为您在开展结构和组织变革时的发展定下了基调。从现在起发现2年你需要这样做会变得更加痛苦。我过去曾经多次使用split dbs，只要你能够对上下文有什么了解，就真的不难处理。这听起来你已经知道客户端就是上下文。
就像我说的那样，只要我的两分钱，你就可以接近主观了。
答案 1 :(得分：4)
如果您计划支持每个客户的自定义，则单独的数据库方法将有效。如果不这样，我没有看到这个值。
答案 2 :(得分：0)
您可以使用链接来连接数据库。 你的架构很聪明。
如果您无法使用链接，您始终可以在只读模式下从用户数据库将关键数据复制到网站数据库。
关于安全性 - 最好的方法是在ASP（或其他网络语言）和数据库之间建立一个服务层 - 这样你的数据库就会非常孤立。
答案 3 :(得分：0)
如果由于负载过重，您希望将来必须在不同的硬件上拆分数据库，我现在就说拆分它。您可以使用复制将某些表的副本从主数据库推送到站点管理数据库。目前，您可以在同一个SQL Server实例上运行这两个数据库，稍后在需要时，可以随着卷的增长将一些数据库移动到单独的计算机上。
答案 4 :(得分：0)
想象一下，我们拥有无限快速的计算机，你会拆分你的数据库吗？当然不是。我们拆分它们的唯一原因是为了让我们在某些时候能够轻松扩展。你在这里没有任何选择，每个客户100MB-1000MB是巨大的。