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

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

• 全面的报告更加容易
• 和代码一样,dry也适用——如果您有多个“克隆”模式,当您需要进行“核心”更改时会发生什么?
• 简化了维护

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

我将使用一个数据库:

• 不幸的是,克隆的数据库文件就是这样的——没有继承树,您可以轻松地建立和持久化基本模式。如果你必须重构或者改变模式,你将陷入困境,试图让你所有的复制品都匹配起来。

• 如果所有东西都在一个地方,维护和移动就更容易了。

• 您可以使用视图为每一个游戏以及每一张牌类型分类相关部分。在一个设计良好的数据库中,信息在必要时会分开显示,但会无缝地连接在一起。

• 作为奖励,你可以开始收集关于不同游戏之间相关性的数据…

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

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

另一方面,如果您在逻辑上为每个纸牌游戏都有一个应用程序实例,那么为每个纸牌游戏都有单独的数据库就更有意义了。

干燥原理。不要重复你自己。我相信尽可能严格遵循干燥原则。把它们放在一个大数据库里。如果你只是克隆数据库,维护将是一场噩梦,重构将是地狱,任何未来的程序员在这个项目上工作将是如此的愚蠢,他们可能会比道路运行速度从狡猾的狼!

首先,选择一个数据库,这样做更有灵活性,也许有些交易卡游戏来自同一家公司,为什么不选择以这种方式拆分数据库(这不是建议),如果您这样做,就不能再次拆分它们,这是一种非常不灵活的方式来组织您的数据,似乎在某种程度上与关系数据库不太兼容。思维方式。

我倾向于将每个数据库放在单独的数据库中。一开始在桌子上放一把辅助钥匙似乎很容易,但这确实会让人头疼。这可能是特别正确的,因为您已经创建了数据库,认为其中只有一种类型的游戏。在所有的查询中都要记住,几乎在任何地方都必须引用第二个键,这是一个经常令人头痛的问题,它显示了应该访问/修改哪个游戏。它可以是一匹真正的夜母马。有一个这样的播客,Spolsky谈到了为什么FogBugs为每个客户机都有一个单独的数据库。(我现在找不到,但我想是20年代中后期)。

为他们所有人修改模式将是一项额外的工作,但是使用工具(如Redgate的工具)这是一项更容易维护的工作。

如果你认为你可能必须从网站上删除一个游戏,独立的DBS也将是一个更容易管理的负载在这种情况下。您不必从一个大型实例中删除所有数据,只需删除与该特定实例相关的数据库即可。

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

编辑: 分离数据库是关于数据完整性的。每个人都在谈论如何维护模式和更新存储过程。我有大约200美元的项目可以帮我完成。没什么大不了的。

我会解释什么是困难的,我害怕把所有的数据库放在一起。

1. 如果你的游戏中有一个需要改变将打破所有其他游戏的模式,会发生什么?(或者更糟的是,你不知道会发生什么)。例如更改数字的大小,或扩展字符串的大小,或向存储过程添加参数。你真是一团糟。您将花费数小时和数小时的额外工作,试图弄清楚一个更改将如何影响接触它的每个其他应用程序。就像触摸一张蜘蛛网。没有,“我们会为这场比赛改变它的。”

2. 如果有人因为错误而运行更新过程来修复数据,而忘记包含适当的标识符,而您更新了表中的所有数据,会发生什么情况?你把所有的事情都搞砸了。

我知道你在说什么,“我们会小心的。”那就是说,“我们不需要测试人员,因为我们为什么要写错误代码?”与走进老板办公室并解释你为什么要在接下来的10个小时里呆在那里相比,花5分钟的额外工作来吸收模式,或者花几个小时让程序员在多个应用程序中审查代码(不管怎样,当有人对他们的应用程序涉及的数据库进行更改时,他们都应该这样做)是个笑话。一个问题,因为有人不完全在他们的游戏中。

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

如果现在将数据库设为多租户,以后如果需要进行相对较小的更改,您仍然可以将它们放在单独的数据库中—另一个方向就不那么容易了。在多租户场景中,您必须假设系统设计得很好,这样您就不会向其他租户泄漏信息。有许多方法可以在视图或SP级别强制执行这一点,以使编码错误可以最小化和减轻的信心达到很好的程度。

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

在SQL Server中,由于ACID完整性和备份的外部单元是数据库,因此拥有非常大的多租户数据库会使得很难满足小型维护窗口的要求。