帮助模拟体育联盟的良好 RDBMS 事务架构设计

Question

我需要为典型的 RDBMS 设计一个数据模型，该模型将模仿典型体育联盟的结构。在架构上我的要求是：

• 标准化良好

• 事务性

• 应用程序开发人员可以使用流行的 ORM 工具对其进行合理建模

所需架构的属性：

• 可以有很多联赛。

• 一个联赛中可能存在 1 个或多个分区。

• 在一个部门中可能存在 1 个或多个会议。

• 单个会议中可能存在 1 个或多个团队。

• 有可能存在1个或多个团队在司当且仅当该分部没有被划分成会议（换句话说，司不需要拆分成会议和代替团队可能会直接有到单个分部的参考而不是会议）

• 单个团队中可能存在 1 名或更多玩家。

• 玩家存在于 1 个且只有 1 个Team 中。

如果联盟结构是僵化的，这将很容易做到并保持参照完整性。这是我的想法，但我想知道这是否是一个好的设计，或者对于这种情况是否有更好的方法。

• 积分榜：...

• LeagueGroup 表：FK - LeagueId NOT NULL，FK - LeagueGroupParentId NULLABLE，LeagueGroupType

• 球队：FK - LeagueGroupId 不为空

• 球员：FK - TeamId 不为空

所以基本上我认为 Divisions 和 Conferences 将是同一个表，带有一个向上查找其分组父级的自引用外键。这样做的好处是联赛分组实际上可以深入N。

缺点是这在 ORM 框架中映射可能不是很容易或有用。此外，应用程序开发人员可能需要编写一些逻辑来将其构建为对他们的目的有用的树状对象结构。此外，如果没有某种触发器，我不知道如何从数据库级别强制团队不能同时存在于部门和会议级别。

您对这种方法有何看法，您是否认为有任何可行的替代方案？

Answer 1

基本思想是将组织结构图的层次结构与实际团队分开。

桌子Level看起来像

LevelID | LevelType
-------------------
  1      League 
  2      Division
  3      Conference
  4      Team_Slot

• Team_Slot 是一个“鸽子洞”，供实际团队随着时间的推移而填补。

还有几点注意事项：

• (PositionID, LevelID)传播备用键是TeamPosition为了允许检查约束 LevelID = 4——实际团队只能填写 Team_Slots。

• 球队在一个赛季内不能更改Team_Slot。

• 为了简单起见，这里使用分级邻接列表对层次结构进行建模；对于 SQL 层次结构来说不是最有效的，但对于解释来说已经足够了。

• 要获得更高效的层次结构模型，请参阅 Celko 的书或直接在 google 上搜索“SQL hierarchies”。