没有域值的表规范化

Question

我们的ETL团队和数据建模师之间就是否应该对表格进行规范化进行了辩论，我希望从在线社区获得一些观点。

目前这些表格都是这样设置的

    MainTable               LookupTable
    PrimaryKey (PK)         Code (PK)
    Code (FK)               Name
    OtherColumns

• 两个表格仅由一个定期文件（来自第三方）填充 通过ETL工作
  • 文件中的单个记录包含单个行的两个表中的所有属性）
• 填充这些表的文件是一个增量（只有在文件中有一些变化的行）
  • 对一条记录的一个属性进行一次更改（同样仅由第三方进行）将导致文件中该记录的所有数据
• 代码和名称的域值是 不已知。

问题：是否应将LookupTable非规范化为MainTable。

• ETL团队：是的。使用此设置，文件中的每一行首先必须检查第二个表以查看它们的FK是否在那里（如果不存在则插入），然后添加MainTable行。更多代码，更糟糕的性能，以及更多的空间。但是，无论第三方对LookupTable.Name的更改如何，定期文件都将反映受影响的每一行，我们仍然需要解析每一行。如果集中在MainTable中，那就是一个简单的更新或插入。
• Data Modeler：这是标准的良好数据库设计。

有什么想法吗？

Answer 1

构建原型。进行测量。

您从这开始，数据建模师说这是一个标准的良好数据库设计。

    MainTable               LookupTable
    PrimaryKey (PK)         Code (PK)
    Code (FK)               Name
    OtherColumns

他是对的。但这也是一个很好的数据库设计。

    MainTable
    PrimaryKey (PK)
    Name
    OtherColumns

如果对这些表的所有更新仅来自ETL作业的 ，则无需非常担心通过外键强制执行数据完整性。无论如何，ETL作业都会向查找表中添加新名称，而不管它们的值是什么。数据完整性主要取决于从 提取数据的系统。 （以及ETL工作的质量。）

  

使用此设置，文件中的每一行都必须首先检查   第二个表，以查看他们的FK是否在那里（如果不是，则插入），然后   添加MainTable行。

如果他们正在逐行处理，请雇用新的ETL人员。严重。

  

更多代码，更糟糕的性能，以及更多的空间。

他们需要一个更多代码来更新两个表而不是一个。编写SQL语句需要多长时间？运行它们需要多长时间？ （每个方向多长时间？）

性能更差？也许。也许不吧。如果使用固定宽度代码（如整数或char（3）），则将更新为代码不会影响行的宽度。由于代码比名称短，因此页面中可能包含更多行。 （使用更长的代码没有任何意义。）每页更多的行通常意味着更少的I / O.

空间更小，当然。因为您在“MainTable”的每一行中都存储了一个短代码而不是一个长名称。

例如，国家/地区名称的平均长度约为11.4个字符。如果使用3个字符的ISO国家/地区代码，则在“MainTable”中每行平均保存8.4个字节。对于1亿行，您可以节省大约8.4亿字节。该查找表的大小可以忽略不计，大约为6k。

你通常不需要加入来获得全名;国家代码在没有扩展的情况下是人类可读的。