Database design 可扩展数据库设计

我有一个后端系统。它需要统一所有游戏（游戏1、游戏2、游戏3等） 我最初的设计是：

一个集中式用户数据库（此处为用户ID和游戏类型），每个游戏驻留在自己的数据库中（此处为游戏类型到用户ID的标记）

然而，由于目前的预算限制，由于选择了托管服务器，数据库必须在一个数据库中。未来可能会扩展（这意味着每个游戏都有自己的用户数据库，不过，用户管理将是另一个复制问题）

---

您知道什么样的设计适合扩展用户管理模块，并尽量减少更改吗？

让我看看我是否理解（我将使用示例）。您正在制作赌场灯光系统，该系统运行各种游戏：21点、吃角子老虎机和轮盘赌。每位客人都会得到一张卡，卡与赌场灯光系统相连，允许他们进入所有三场比赛。到目前为止，这是正确的吗？对于记录来说，将它们保存在同一个数据库中可能会更快。您不能很好地跨数据库维护外键（您的用户ID需要外键）（如果有的话）。为了便于组织，您可以在游戏特定表格（21点游戏、21点手牌等）的开头预先添加一个标签。克里斯：第一条评论是宾果。第二句话：绝对更快。有一段时间，Blackjack的用户可能太多，因此管理层担心可能需要隔离。我关心的是如何在存储过程中处理“四部分命名约定”，因为几乎所有开发人员都可以直接访问表。在存储过程中封装可能有点困难。EF绝对不是我的选择，因为在dbs，我害怕MSDTC。