数据库设计——一个数据库，多个站点

Question

我知道这个问题以前已经被问过很多次了，但我找不到我的确切答案。所以请让我在这里问一下。

我们构建了一个 CMS 来控制一个站点。现在公司正在扩张，我们有几个核心结构几乎相同的站点。为了便于以后维护，我们决定使用一个数据库。

我们大约有10张桌子。例如，页面、新闻、设置（每个站点都不同）...

如果我们向每个表添加一个 App_ID（或 Site_ID）列，以便我们知道其中的哪些记录，这听起来不是一个好主意我们应该撤出的特定网站。

例如，

PAGES:
PageID   |   Body   |   SiteID
1        | abc      |   1
2        | cde      |   1
3        | aafd     |   2
4        | gsgs     |   2
5        | feg      |   3

我认为将这个 SiteID 列添加到该数据库中的每个表中是非常丰富的。

我仔细查看了多租户架构 但我不知道如何将其应用到我们网站的 CMS 中。

遇到这种情况，最好的处理方法是什么，请帮忙。任何启发都值得赞赏。

简单的代码

Answer 1

我们最近一直在审查多租户单一数据库的各种策略。

如果您不想将站点标识符添加到表中，那么您可以为每个租户提供自己的架构和表集。每个租户都可以拥有自己的连接字符串，该字符串仅提供对其架构的访问（您显然需要在运行时切换连接（如果您使用这些，那么使用 EF 和 NH 就足够简单了）。

但是，我们选择的选项是引入在我们的应用程序中添加一个附加级别，以便应用程序的每个组件（在您的情况下是新闻、页面等）都表示为数据库中的一个功能，

然后每个站点都有一个功能“实例”的集合以及为每个实例存储的数据。这些功能（博客可能有帖子、标签、类别）引用了功能实例（而不是网站），

这确实增加了额外的复杂性，但我们发现它非常灵活，并且将我们的功能数据与网站分离（使 ）。如果我们愿意，可以在站点之间移动功能实例）。

Answer 2

答案不一。在类似的项目、相同的数据库结构、多个站点中工作。

我们尝试了几种东西。

我们是“最佳实践”、“数据库规范化”、“设计模式”的粉丝，但是，我们最终使用的是实用方法，而不是理论方法。

我们为每个站点/公司都有一个或多个数据库，每个数据库表都有一个“site_id”，并且它有效。

我们遇到过一些情况，一家公司决定为每个部门拆分其数据库站点，因此一个数据库变成了多个数据库，有时位于同一数据库服务器中，有时位于不同的数据库服务器中。

我们有一个案例，一家只有一个站点的公司，收购了一家较小的公司，添加了一个具有相同数据库结构的新站点，五年后，他们合并了数据。

几个站点加上“site_id”，效果很好。

Answer 3

推荐使用多个数据库，因为它可以更简单地备份和恢复单个站点。此外，如果您发现需要引入复制从属服务器，则使用单独的数据库可以提高复制效率。据我所知，大多数多站点托管解决方案都使用多个数据库。

但是，如果您打算使用单个数据库，则另一个选项是复制表，并使用指示其所属站点的前缀。