假设我有名为客户、国家、州和城市的数据库表。单个客户将有一个 CityID 字段，该字段链接到 Cities 表。每个城市都有一个 StateID 字段，该字段链接到 states 表，对于国家/地区也是如此。
当我们知道客户的完整地址时，这一切都很简单，但有时我们只有他们的国家，有时只有国家。我们并不总是拥有这座城市。
我们如何处理这个？我们希望能够拯救国家，但如果我们不了解这座城市，我们就做不到。
我们可以将 StateID 和 CountryID 字段添加到客户表中，但这听起来像是糟糕的设计，并且可能导致数据不一致。
有人有什么建议吗？我确信这是一个非常标准的问题，但我找不到一个好的答案。
PS 在回答下面 Jaffar 的评论时，这样做的原因是我们需要对我们的客户分布在哪里进行一些分析。客户向医院集团出售极其昂贵的医疗扫描仪，并且并不总是知道在订购扫描仪时哪个站点将接收扫描仪。因此，我们需要能够指定尽可能多的信息，可能只是国家，可能是州，也可能是城市。
我们目前只需要为美国执行此操作，但如果客户希望将分析扩展到其他国家/地区，我们更愿意提供灵活的方法。
如果您查看任何数据模型模式书籍，您会发现它们抽象了地缘政治领域。
使用表继承。
国家/地区扩展了地缘政治区域，州/省、县、市也是如此（尽管不是邮政编码或大陆）。
您现在可以使用带有外键的一列将客户指向任何地缘政治区域。如果你把它指向一个城市，你可以推导出州、国家。如果你把它指向国家，那么至少你知道这个国家。
这对于按县、州、国家跟踪税率也很有用。
正如理查德建议的那样，我在dba.stackoverflow.com上提出了问题，尽管我提出的问题略有不同。我提出了三种解决方案，三表方法（Richard 喜欢），自引用 Locations 表方法（我认为查询起来会很复杂）和 Juhana 使用三个表的方法，但包括一个空白条目（在我看来是最简单的）。
按照那里的两个回复（如果您想完整查看它们，请点击链接），我尝试了自引用位置表方法，发现它比我想象的要容易得多。它在所有方法中具有最大的灵活性，因为它允许我链接到任何级别的区域，包括尚未考虑的额外级别，不需要来自客户表的多个链接，但不涉及复杂的查询。
我不知道在纯 SQL 数据访问中使用这种方法是否会那么容易，但是当我使用 ORM 时，子位置被具体化为实体上的集合属性，使导航变得非常简单。
感谢所有回复的人。我希望这对其他人有帮助。
在城市名称为空的城市表中为每个州制作一行，在城市和州为空的每个国家/地区制作一行。当城市或州未知时使用它们。
我认为你的设计是错误的。您不应该需要 CityID 来获取州或 StatID 来获取 Country。
如果人们住在一个州的一部分而不是在城市里怎么办？如果他们住在不属于某个州的国家（或没有州的国家）的部分地区怎么办？如果他们生活在一个城市、州和国家都一样的城邦怎么办？
[UserID]
[Address Line 1]
[Address Line 2]
[Address Line 3]
[Address Line 4]
[CityID]
[StateID]
[CountryID]
[Zip Code]
使它们都成为外键。
此外，如果您想尽可能灵活，则要求城市、州和国家绝对与该方法相反。
关于这个主题的一个很好的帖子住在这里：世界上所有地址是否有共同的街道地址数据库设计？此外，城市、国家和无州 存在有效组合。
[编辑]
因为有很多反对者应该是标准数据库设计......
梵蒂冈城地址（无城市，无州）
His Holiness Pope Francis
Apostolic Palace
Vatican City
关岛 Hard Rock Cafe 的地址（无州）
Hard Rock Cafe Guam
1273 Pale San Vitores Road
Tamuning, Guam 96913
表示这两个地址的唯一方法是使用三个非链接字段：
[城市] [州] [国家]
这是地址表的标准设计。