7
通过将街道地址分成多个单独的列可以解决哪些问题？
我们有一个团队为软件开发人员设计表格和关系。在我们的组织中，他们对执行3NF标准化非常严格-坦白地说，鉴于我们的组织规模以及需求或客户随时间的变化，我同意。我对他们的设计决定背后的原因只有一个不清楚的地方：地址。 虽然这主要针对美国的地址，但我认为这可以适用于任何这样做的国家。地址的每个部分在地址表中都有自己的列。例如，以这个肮脏的美国地址为例： Attn: Jane Doe 485 1/2 N Smith St SW, APT 300B Chicago, IL 11111-2222 它会像这样在数据库中拆分： 街道号：485 街道分数：1/2 街道定向：N（北） 街道名称：史密斯 街道类型：ST（街道） 街后：SW（西南） 城市：芝加哥 州：IL（伊利诺伊州） 邮政编码：11111 邮政编码：2222 国家（假设为美国） 注意：Jane Doe 邮政信箱：NULL 居住类型：APT（公寓） 居住人数：300B 并且还会有其他几列与乡村路线和合同路线相关。此外，我们的特定应用程序可能会包含一些国际地址。数据建模人员表示，他们将添加特定于国际地址的列，即通常的第1行，第2行字段。 起初我以为这太过分了。反复进行在线研究是指使用地址行1、2、3和可能的4，然后划分城市，地区和邮政编码。对于这种粒度很有用的新应用程序，我们确实有一个用例。我们必须验证用户没有创建重复业务，并且检查地址是验证之一。我们可以使其与地址线1和2一起使用，但这会更加困难。 对于我们的特定应用程序，我们需要为企业和个人存储多种地址（实体地址，邮件地址，运输地址等）。我们可能需要生成可打印的套用信函，但到目前为止尚未讨论该要求。 我们组织中的应用程序还需要支持其他一些功能： 审核（带有完整的历史记录表） 打印邮件标签 生成打印表格 报告（针对国家和地区政府） 虽然我们的应用程序可能无法像其他应用程序那样做所有事情，但是将地址拆分为多个组件是我工作的企业标准。无论我们的应用程序是否将从中受益，我们都被迫这样做。 半相关的StackOverflow问题：一个好的地址解析器在哪里被关闭，但是它说明了解析地址有多困难。 为了让我更好地了解他们的设计决策，并向我们的客户推销该想法... 将街道地址分为几列可以解决哪些问题？ 对于实施了这样的系统的任何人，如果他们遇到了问题，就会获得加分。