优化 National ZIP+4 数据库以实现快速地址查找答案

【问题标题】：Optimizing National ZIP+4 database for fast address lookup优化 National ZIP+4 数据库以实现快速地址查找
【发布时间】：2013-06-14 06:13:29
【问题描述】：

我刚刚获得了一大组文本文件（总共 8 GB），其中包含美国境内的所有地址范围。该文件集包括：

929 个 ZIP+4 文件，每个文件包含唯一的邮政地址三位数的邮政编码。例如，文件 606 将仅包含具有以 606 开头的五位数邮政编码的地址。这些文件中的记录总数约为 30 百万。
城市状态文件，包含邮政编码和他们对应的城市和州。

City State Key 可用于将 City State 文件加入 ZIP+4 文件。

鉴于数据库的规模和我缺乏经验，我想在开始这项工作之前获得一些见解。 ZIP+4 文件应该合并成一个怪物文件，然后使用邮政编码进行索引，还是用三位邮政编码分隔，以便将三位邮政编码文件名用作块匹配标准？如果是后者，那这不是分层数据库模型吗？我可以使用分层模型来适应与 City State 文件的关系吗？

上面对数据集的描述是一个巨大的简化，但出于这个问题的目的，没有必要进行详细的描述。完整的描述可以在here 找到。

我正在使用 Python，但尚未决定使用 RDBMS。任何帮助将不胜感激！

【问题讨论】：

标签： python database-design postal-code

【解决方案1】：

如果您要使用 RDBMS，您最终将在一个数据库中拥有所有 929 个文件的内容，很可能在多个表中。我无法告诉您更多有关此类数据库设计的信息，因为您没有提供有关每个文件内容的足够详细信息。确切的布局将是您可能在少数几个表中的 3000 万行的规范化形式。如果（且仅当）您的索引设置正确，现代 RDBMS 的性能足以处理这种规模的数据。

几乎没有理由不将该数据放入 RDBMS。我能想到的唯一原因是完全消除对这样一个子系统的需求，例如简化解决方案的部署。如果您真的考虑这样做，那么可以，一组 929 个文件可以充当分层数据库。与 RDBMS 解决方案的主要区别在于，对于这样一组平面文件，您只能通过一个键（即您的邮政编码（或其任何部分））合理地查询您的数据。

【讨论】：

Hazzit，这也是我对局限性的理解。我可以将具有唯一五位数邮政编码的地址划分为单独的文本文件，并将文本文件排列在包含唯一三位数邮政编码的目录中。因此，搜索包含邮政编码 60601 的地址将搜索 606 目录，然后搜索 60601 文本文件。但正如您所提到的，我只能使用一个键进行查询 - 邮政编码。如果五位邮政编码不匹配，我需要想办法通过三位邮政编码或城市有效地查询。
@user1185790 如果您的用例需要不同的密钥，那么您绝对应该使用 RDBMS。
谢谢哈兹特！我将使用 RDBMS 并在查询字段上应用复合索引。也许一个复合索引由五位邮政编码、地址组成，另一个由城市、地址组成，另一个由三位邮政编码、地址组成。
@user1185790 在不了解您的应用程序的情况下，请注意：邮政编码上的简单（非复合）索引也会自动充当其前三位的索引。一个关于 City 的简单索引可能是您唯一需要的其他索引。