关于sql：在关系数据库中建模地理位置

我正在设计一个联系人管理系统，并且遇到了有关以一致方式对地理位置建模的有趣问题。 我希望能够记录与特定人相关的位置(用于工作，学校，家庭等的邮寄地址)。我的想法是创建一个区域表，例如：

自治位置(例如国家/地区，例如美国)为其自身的父级的语言环境(ID，LocationName，ParentID)。 这样，我可以任意深度地嵌套"政治单位"("国家">"州">"城市"或"国家/地区">"州">"城市">"大学")。 一些查询必然涉及递归。

对于使用这种方案可能遇到的可预见问题，我将不胜感激。

---

您可能想看看Freebase.com这个站点，它已经就"位置"的含义以及在另一个位置包含一个位置的含义进行了公开讨论。这些问题可以引起很多讨论。

例如，存在明显的"地理嵌套"，但是不那么明显的逻辑嵌套。例如，从严格的地理意义上讲，梵蒂冈城位于意大利境内。但这并不是政治上的嵌套。同样，如果您的用户位于一所大学的研究中心内，但又不在该大学的财产范围内，您是否对这种关系进行建模？

---

听起来对我来说是个好方法。在阅读您的文章时，我不清楚的一件事是"自己的父母"的含义-如果这是为了指示语言环境没有父母，那么最好使用null而不是其自身的ID。

---

我认为您可能对此想法有所怀疑。大多数系统都有一个原因，就是仅存储地址，可能还存储国家/地区表。这里有一些注意事项：

布朗克斯区中的地址是否将自治市镇作为层次结构中的一个级别？非合并区域中的地址会消除层次结构的"城市"级别吗？如何对大学内的地址与不在大学内的地址进行建模？您最终将得到一个参差不齐的层次结构，这将迫使您每次需要在应用程序中显示地址时都要遍历树。如果您有一个"通讯录"页面，那么对性能的影响可能很大。

我不确定您是否只有一个层次结构。布朗大学在罗得岛州普罗维登斯和罗得岛州布里斯托尔设有设施。唯一的干净解决方案是拥有一个双重层次结构，其中包含两个校园，每个校园在一个层次结构中分别属于各自的城市，但在另一个层次结构中均属于布朗大学。 (大学从根本上与政治地区不同。您不应该将它们混为一谈。)

邮政编码呢？一些邮政编码包含多个城镇，而另一些城市则分为多个邮政编码。并且(很少)一些邮政编码甚至跨越州际线。 (根据维基百科，至少...)

您将如何输入数据？当您考虑虚荣地址，某些街道的备用名称，不同的国际格式等时，通过解析常规格式的地址来构建数据库可能会很困难。我认为，分等级地输入每个地址都是PITA。

听起来您正在尝试在应用程序中为整个世界建模。您是否真的想要或需要维护一个可以想象包含世界上每个城市，州，省，邮政编码和国家的表格？ (或者至少每个人都认识某个人？)我唯一能想到的是，该方案可以为您带来方便，但是如果您要这样做，我将州和国家/地区(或邮政编码)分别存储并从Google添加纬度和经度数据。

对极端的悲观主义感到抱歉，但是我本人已经走了这条路。从逻辑上讲，它美观大方，但在实践中效果并不理想。

---

这是一个非常灵活的架构的建议。立即警告：对于您实际需要的可能太灵活/太复杂

位置
(LocationID，LocationName)
-基本组成部分

位置组
(LocationGroupID，LocationGroupName，ParentLocationGroupID)
-这可以有效地封装多个层次结构。您有一个根节点，然后可以创建多个独立分支。例如。您可以先按州划分，然后创建几个子层次结构，例如邮编/城市/ xxxx

LocationGroupLocation
(LocationID，LocationGroupID)
-这是将位置与一个或多个层次结构链接的方式。例如。您可以将房屋链接到ZIP，也可以链接到城市...您需要实现的约束是，您不能将位置与任何两个层次结构链接在一起，而其中两个层次结构是另一个层次结构的父级(因为该关系已经是隐式的)。

---

我会仔细考虑一下，因为它可能不是必需的功能。
为什么不只使用文本字段并让用户输入地址？

记住KISS原则(保持简单，愚蠢)。

---

对于地理位置，您可能希望将地址解析为纬度，经度数组(可能使用Google地图等)以计算邻近度等。对于地缘嵌套，我会选择KISS响应。

如果您真的想对其建模，则可能需要更通用的类型...国家->省->县->自治市镇->地点->城市->郊区->街道或邮政信箱->数字-> ->公寓等->机构(大学或雇主)->部门->细分1->细分n ...您确定不能做KISS吗？

---

我同意其他帖子，在这里您需要特别注意自己的要求。位置可能成为棘手的问题，这就是GIS系统如此复杂的原因。

如果您确定只需要一个基本的层次结构，我有以下建议：

• 我支持先前的评论，即根级项目不应该将自己作为父项。根级项目的父级应为空值。始终小心将数据放入没有意义的字段(即"特殊"值表示没有数据)。这种做法在开发者社区中很少有必要被滥用。
• 考虑XPath / XML。这是考虑记录分层结构以及在检索时处理/解析数据的考虑因素。如果您使用的是MSSQL Server，则select语句中的XPath表达式非常适合执行诸如返回记录的完整位置/层次结构路径之类的任务，因为代码简单且结果快速。

---

我正在为全球用户建模应用程序，但我遇到了同样的问题，但是我认为这种方法可能已经在许多企业中使用。但是，为什么这个问题没有通用的解决方案？或者，这个问题是否可以作为起点的最佳解决方案，或者自从开始以来世界上任何人都需要考虑解决方案？
不幸的是，在IT领域，我们随时随地都在做同样的事情。例如，谁创造的用户，客户或产品数据库不止一个？最糟糕的是，世界上所有企业都做到了。我认为这可以为普遍问题提供普遍解决方案。

---