相关疑难解决方法(0)

我们有一个团队为软件开发人员设计表格和关系。在我们的组织中，他们对执行 3NF 规范化非常严格——老实说，鉴于我们组织的规模以及需求或我们的客户如何随时间变化，我同意这一点。只有一个方面我不清楚他们设计决策背后的原因：地址。

虽然这主要集中在美国的地址，但我认为这适用于任何这样做的国家。地址的每一部分在地址表中都有自己的列。例如，以这个粗糙的美国地址为例：

Attn: Jane Doe
485 1/2 N Smith St SW, APT 300B
Chicago, IL 11111-2222

它会像这样在数据库中拆分：

• 街道号码：485
• 街道分数：1/2
• 街道预定向：N（北）
• 街道名称：史密斯
• 街道类型：ST（街道）
• 街道后向：西南（西南）
• 城市：芝加哥
• 州：IL（伊利诺伊州）
• 邮编：11111
• 邮政编码：2222
• 国家（假设为美国）
• 注意：简·多伊
• 邮政信箱： NULL
• 户型：APT（公寓）
• 户数：300B

还会有一些其他与农村路线和合同路线相关的专栏。此外，我们的特定应用程序中可能会包含一些国际地址。数据建模人员表示，他们将添加特定于国际地址的列，这将是正常的第 1 行、第 2 行字段。

起初我认为这太过分了。在网上反复搜索是指使用地址行 1、2、3 和可能的 4，然后拆分出城市、地区和邮政编码。我们的新应用程序确实有一个用例，这种粒度是有益的。我们必须验证用户没有创建重复的业务，检查地址是验证之一。我们可以让它与地址行 1 和 2 一起工作，但这会更困难。

至于我们的具体应用，我们需要为企业和个人存储多种地址（物理、邮寄、运输等）。我们可能需要生成可打印的套用信函，但目前尚未讨论该要求。

我们组织中的应用程序需要支持的其他一些东西：

• 审计（使用完整的历史表）
• 打印邮寄标签
• 生成打印表格
• 报告（针对国家和地区政府）

虽然我们的应用程序可能不会做所有其他应用程序正在做的所有事情，但将地址拆分为多个组件是我工作的企业标准。不管我们的应用程序是否会从中受益，我们都被迫这样做。

半相关的 StackOverflow 问题：关闭的好的地址解析器在哪里，但说明解析地址有多么困难。

为了让我更好地理解他们的设计决策，并把这个想法卖给我们的客户……

将街道地址拆分为单独的列解决了哪些问题？

任何实施过此类系统的人都会获得奖励积分，因为他们遇到了问题。

我需要为我的网站实现基本的个性化用户功能。这种类型的数据库有标准结构吗？就像将所有用户信息和数据放在一个表中并且每个用户都有自己的行一样是常见的做法，还是应该将这些信息拆分到不同的表中并链接在一起（也许是为了效率？）我不太关心安全性在这一点上，但我显然希望在不久之后进行密码加密。

我试图在谷歌上找到我想要的东西，但无济于事。如果问题需要进一步澄清或任何其他内容，请告诉我。

我想开始在我的网站上实现用户功能，但我不确定我应该存储什么样的信息。显然，用户名、密码、密码哈希、真实姓名、电子邮件等基本信息……但是，一般来说，了解用户的其他一些信息可能有用吗？（我一直在折腾诸如上次登录、登录位置之类的东西）