如何针对这些需求设计 SQL 表

Posted 2023-05-08

【中文标题】如何针对这些需求设计 SQL 表

【英文标题】：How design SQL tables for these requirements

【发布时间】：2011-05-18 05:02:53

【问题描述】：

我有CITY 和AREA 的数据。

每个CITY 有多个AREAS 每个AREA有多个AREAS（这里没有尽头，用户可以在子AREA下动态添加AREASlikeAREA->AREA->Area->AREA....->AREA）

那么，如何设计出满足这些要求的表结构呢？

提前致谢。

【问题讨论】：

每个区域是否有多个 CHILD 区域、多个 PARENT 区域或两者都有？

【参考方案1】：

城市表

城市 ID (PK) 城市名称

城市区域表

CityID（复合（两列）PKey） AreaID（如果您希望某个区域只能由一个城市拥有，请在此列中添加唯一索引）

面积表

AreaID (PK) 地区名称

区域面积映射表

AreaID（所有者区域）（复合（两列）PKey） 区域 ID

规则

为了将一个区域映射到另一个区域，Areas 表中的每个区域都必须有一条记录。 在区域区域映射表中，您必须确定这些关系是双向的还是单向的。在我看来，这将是一种方式。第一个 AreaID 是拥有第二个 AreaID 的区域。

【讨论】：

在您的示例中，一个区域可以属于许多城市，也可以属于许多区域。在他的描述中，看起来只有一个城市可以有很多区域，一个区域可以有很多子区域。这些是一对多的关系，而不是多对多

好点，在 Cita Areas 表上使用唯一索引固定。但是，我不认为我们可以排除一个区域可能由多个区域拥有。示例：The Park 归 The Block 拥有，而 The Block 归 The Neighborhood 拥有。虽然最好有一个所有权链，但这里的问题有点模糊。

注意，如果一个区域只能由一个城市拥有，从技术上讲，城市区域可以在 AreaID 上单独拥有一个 PKey。但是，为了便于其他编码人员理解，我可能会保留两列 PKEY 和唯一约束。

添加唯一的复合 PK 并不能解决多对多的问题。示例 AreaId 20、CityId 30 和 AreaId 20 与 CityId 40 - 它们都是唯一的一对，并且区域 20 属于两个城市（30 和 40），这是不好的 - AreaArea 表也是如此。你的设计允许一个区域有多个父节点——我的不允许

数据透视表（包含复合主键的表）用于 m 对 n 关系 - 当有人使用它们来建模 1 对 n 关系时会令人困惑

【参考方案2】：

表区域：

id (PK) parent_area_id - 它所属的区域 - 如果没有父区域（AREA 表上的 FK）可以为 NULL city_id - 它所属的城市 - 如果 parent_area_id 完成，您可以从业务逻辑中强制 city_id 为 NULL，反之亦然（城市表上的 FK） 其他有用的列

表城市：

id (PK) 其他有用信息

您可能有兴趣阅读Managing Hierarchical Data in mysql - 它也适用于其他数据库引擎

【讨论】：

+1 用于提及嵌套集（在链接中）。我没有尝试过它们，但看起来它们在某些情况下可能会快得多。这是来自 Joe Celko 的an article on the subject

【参考方案3】：

那将是一棵树（或者可能是一个层次结构）。您将在此处的其他答案中看到最常见的解决方案是使用邻接列表模型。然而，另一个需要考虑的“大”想法是嵌套集模型。关于这个主题的一本有用的书是Joe Celko's Trees and hierarchies in SQL。

【参考方案4】：

自反关系。

或者，如果您更喜欢 nested sets。

【参考方案5】：

对于 SQL Server 2008，选择是层次结构数据类型

这是一个关于performance 的链接