数据库贯穿式设计与快速和肮脏的设计比较

den*_*ini 3 database-design database-recommendation

以一个地址的表示为例,下面是一个完整且非常详细的实现:

地址表示

这里是一个快速实现(或多或少包含相同的字段,想象前者中的所有字段也包含在第二个中)

地址表示快速

如果我要决定哪个更接近规范化和学术上正确的,我会说第一个,但是如果我要开始一个项目,我会选择第二个。

你同意这个考虑吗?如果是,人们如何处理这一事实?

  1. 从一个简单的数据库开始,一到时候就将其改进为更规范化/学术化的数据库。
  2. 从尽可能接近学术数据库的内容开始
  3. 坚持快速而肮脏的解决方案

Joe*_*own 8

尝试标准化地址通常是一个坏主意。规范化地址没有太多价值。您的两种设计都不适合绝大多数系统。

您通常对地址做两件事:

  1. 使用它们将邮件或包裹发送到该位置。
  2. 使用它们对该位置进行地理空间分析。

例如,由于您在设计中使用州、省和行政区,而不是县,因此我假设您在北美环境中工作。如果这是真的,那么您已经建立了完善的邮政机构(USPS、CPC),并拥有监管良好的邮政数据和现成的地址数据质量工具。即使您在美国/加拿大以外的地方工作,也可能有数据质量工具可以满足您的需求。

通过验证标准化您的地址数据,您可以确保您能够实现您的第一个目标。

在美国使用 ZIP+4,在许多其他国家/地区使用 Postal Code,您可以获得实现第二个目标所需的一切。

很多人真的很想将地址分解为细粒度的字段。这是对当您只有“address_line_1,address_line_2,...”时地址数据通常有多糟糕的反应。然而,将糟糕的、未经验证的城市名称分解到自己的领域中只会意味着你得到了一小堆垃圾而不是一大堆垃圾。解决此问题的唯一方法是使用地址数据质量工具来验证和标准化您的地址。如果您尝试标准化您的地址数据,您最终会得到一大堆多对多关联。这是因为现实生活中的地址不符合您在教科书中看到的整洁层次结构。

除非您对地址有一些真正特殊的需求,否则只需保持您的表格简单(几行地址行,可能会破坏邮政编码)并使用良好的地址数据质量工具来清理输入的数据。