2

所以我四处寻找，但没有找到满意的答案。

如标题所述，我有不同类型的位置。给定一种类型的位置（即城市），可以推断出粒度较小的位置。即，如果您知道您在俄勒冈州，则意味着您在美国，这意味着您在北美。

我们有引用位置的对象，但粒度并不完全相同。有些项目可能指向社区，有些项目只知道到城市级别，而有些项目只知道一个地区，等等。

我想到了两种组织数据的方式，这是我倾向于的方式：

  • 有一个通用的“位置”表，其中有一个位置“类型”和一个引用自身的“父位置”。所以会有一个美国类型的国家条目，以及一个引用美国的俄勒冈州类型的条目。IE

在此处输入图像描述

然后，您可以让对象引用其主键之外的位置，然后可以推断出其他位置。这有意义还是有更好的方法可以组织数据？

  • 我考虑的另一种方法是为每个位置“类型”使用不同的表，但问题是我们的对象引用它，因为对象的最细粒度类型的位置并不总是相同的。

如果我稍后将其他位置类型滑入，例如城市和地区之间的县，这可能会出现问题吗？我认为这不会比使用单独的表更成问题，但也许有更好的方法可以让我以合乎逻辑的方式跟踪事物。

4

3 回答 3

1

这是子类的一种情况，通常称为子类型。一些子类型包含在其他子类型中的事实使情况变得复杂。经典的基本关系数据库设计很好地处理了容器问题。

子类问题需要一点解释。OOP 所称的“子类”在 ER 建模界被称为“ER 专业化”。这告诉您如何绘制子类，但不会告诉您如何实现它们。

值得一提的是在 SQL 表中实现子类的两种技术。第一个名称为“单表继承”。第二个名称为“类表继承”。在类表继承中，您将拥有一个用于“位置”的通用表，其中包含所有位置共有的所有属性，无论类型如何。在“城市”表中，您将拥有与城市相关的属性，但与国家/地区等无关。您将拥有其他类型位置的其他子类表。

如果你走这条路，你应该查找另一种技术，称为“共享主密钥”。在这种技术中，子类表的 id 字段都包含来自超类表的 id 字段的副本。这需要一点努力，但非常值得。

共享主键提供了几个优点。它强制执行子类关系的一对一性质。它使将专用数据与通用数据连接起来变得简单、容易和快速。它跟踪哪些项目属于哪个子类，没有额外的字段。

在您的情况下，还有另一个优势。使用外键引用位置的其他表不必决定是引用超类表还是子类表。引用超类表的单个外键也将隐式引用子类表之一，尽管不清楚是哪一个。

这并不完美，但它非常非常好。去过也做过。

有关更多信息，您可以 google 技术，或在 SO 中找到相关标签。

于 2012-11-07T14:18:15.287 回答
0

关于什么：

国家：

  • Id,
  • Name.

地区：

  • Id,
  • CityId,
  • Name.

城市：

  • Id,
  • RegionId,
  • Name.

社区：

  • Id,
  • CityId,
  • Name.

这适用于位置类型。但你的主要问题是

但粒度并不完全相同。

为了这：

目的：

  • Id,
  • Name,
  • LocationId,
  • Type.
于 2012-11-06T19:24:58.163 回答
0

好问题。

你绝对应该选择你的第一个选择。如果您查看任何数据建模模式书籍，它们都会选择这种方式。

这是北美唯一的，还是全球的？

问题：

Cities/Towns/Hamlets/Villages 是 Divisions 的子项（州/省的通用术语），但不在英格兰，它们是 Country（或者是 County）的子项

邮政区（邮政编码、邮政编码）也是部门的子级，而不是县或市。有些城市完全驻留在拉链中，有些拉链完全驻留在城市中

县也是师的孩子。曼哈顿包含县，而大多数县包含城市。

如果您希望获得全球解决方案，我会阅读 Hay 的企业模型模式。它在 safari 上很便宜。

于 2012-11-06T20:41:44.043 回答