什么是最好的：单独的数据库或额外的“代码”表？

Question

我有一个数据库，旨在保存各种交易卡游戏中的卡数据。到目前为止，我一直在跟踪一个纸牌游戏，但我使用的是属性表，因为并非所有属性都适用于每张卡。

我现在正在扩展到多个纸牌游戏，并且有大量数据准备好迁移。但是，我不太确定如何导入这些数据。我是否应该简单地将模式克隆到新的数据库中纸牌游戏，所以我可以在不同的桶中管理东西？或者我应该简单地添加一个名为“CardGame”的新表，并使用该唯一标识符作为卡的外键，并为其创建一个庞大的数据库。

如果对于这种情况有任何影响，这个主数据库会发布到一个网站供用户查询，以及分解为人们可以使用的WinForms应用程序的小型数据模块（每个游戏）。

Answer 1

我在这些情况下的一般偏好是使用一个数据库，原因如下：

• 使综合报告变得更加容易
• 与代码一样，DRY适用 - 如果您有多个'克隆'架构，当您需要进行“核心”更改时会发生什么？
• 维护简化

但决定最终取决于你的具体要求......

Answer 2

我会使用一个数据库：

• 不幸的是，克隆的数据库文件就是这样 - 没有继承树，您可以轻松地制作和持久化基础架构。如果您不得不重构或更改架构，那么您将陷入困境，试图让所有克隆都匹配。

• 如果一切都在一个地方，那么维护和移动会更容易。

• 您可以使用视图来分类每个游戏的相关部分以及每种卡类型。在设计良好的数据库中，信息将在必要时单独显示，然后无缝连接在一起。

• 作为奖励，您可以开始收集有关不同游戏之间相关性的数据......

Answer 3

我认为这实际上取决于单个应用程序是否会使用来自不同纸牌游戏的数据。

我有一个应用程序可以处理来自一个游戏的数据，而不是单个数据库是有意义的。

另一方面，如果你在每个纸牌游戏中逻辑上有一个应用程序实例，那么每个纸牌游戏都有一个单独的数据库，这样做会更有意义。

Answer 4

我倾向于将每个人放在一个单独的数据库中。首先在桌子上放置辅助钥匙似乎很容易，但实际上可能导致头痛。这可能尤其如此，因为您已经创建了数据库，认为只有一种类型的游戏会在其中。在你的所有查询中都要记住，你必须在几乎所有地方引用第二个键来显示应该访问/修改哪个游戏。它可以是一个真正的夜间母马。有一个SO播客，其中Spolsky谈论为什么FogBugs为每个客户提供一个单独的数据库。 （我现在找不到它，但我认为是20年代中后期）。

在未来的路上修改所有这些模式将是一项额外的工作，但使用工具（如RedGate中的工具），这是更加可维护的。

如果您认为可能必须从网站中删除游戏，则在这种情况下，单独的dbs也将更容易管理。您只需删除与该特定实例相关的数据库，而不是从一个大数据中删除所有数据。

报告所有数据也是一项工作，因为它们都在单独的dbs中。我会将所有dbs中的所有数据汇总到一个严格用于报告的报告数据库中。再一点额外的工作，但不是太难。

编辑： 分离数据库是关于数据完整性的。每个人都在谈论如何难以维护模式和更新存储过程。我的程序花费大约200美元，这对我来说。没什么大不了的。

我将通过将所有数据库放在一起来解释什么是困难而且我很害怕。

1. 如果您的某个游戏需要更改会破坏所有其他游戏的架构，会发生什么？ （或者更糟糕的是，你不知道会发生什么）。比如更改数字的大小，或扩展字符串的大小，或者将参数添加到存储过程。你几乎完全搞砸了。您将花费数小时的额外工作来试图弄清楚一个更改将如何影响触及它的每个其他应用程序。这就像触摸蜘蛛网。没有，“我们只是为这场比赛改变它。”

2. 当有人因为错误而运行更新程序来修复数据并忘记包含相应的标识符并更新表中的所有数据时会发生什么？你把一切都搞定了。

我知道你在说什么，“我们要小心。”这正是说，“我们不需要测试人员，因为我们为什么要编写错误代码？”下载模式的额外工作需要花费五分钟，或者程序员需要花费额外的时间来查看多个应用程序中的代码（当有人对应用程序触及的数据库进行更改时，他们应该这样做）与进入应用程序相比是一个笑话。你的老板的办公室，并解释为什么你会在接下来的10个小时内到达那里解决问题，因为有人并没有完全参与他们的比赛。

Answer 5

DRY原则。不要重复自己。我相信尽可能严格遵守DRY原则。将它保存在一个大数据库中。如果你只是克隆db，维护将是一场噩梦，重构将是地狱，任何未来的程序员都会如此傻眼，他们可能比Wily Coyote的Road Runner跑得更快！

Answer 6

首先去一个数据库有更多的灵活性可能一些交易卡游戏来自同一家公司为什么不选择以这种方式分割你的数据库（这不是一个建议），如果你这样做你不能再拆分它是一种非常不灵活的组织数据的方式，似乎与关系数据库的思维方式不太相容。

Answer 7

我认为尽早进入多租户是一个好主意。

如果您现在创建数据库多租户，如果您想要进行相对较小的更改，您仍然可以将它们放在单独的数据库中 - 另一个方向并不那么容易。您必须在多租户场景中假设系统将经过精心设计，以便您不会向其他租户泄漏信息。有许多方法可以在视图或SP级别强制执行此操作，以便充分确信编码错误可以最小化和减轻。

您还可以将游戏分发到数据库中。造成这种隔离的原因有很多。它可能不适用于您，但对于超大型数据库，从维护窗口的角度来看，有时候有多个多租户数据库是有意义的。例如，按国家或时区。

在SQL Server中，由于ACID完整性和备份的外部单元是数据库，因此具有极大的多租户数据库会使得难以满足小型维护窗口。