0

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

目前这些表是这样设置的

    主表查找表
    主键 (PK) 代码 (PK)
    代码 (FK) 名称
    其他列
  • 这两个表仅由定期文件（来自第 3 方）通过 ETL 作业填充
    • 文件中的单个记录包含单个行的两个表中的所有属性）
  • 填充这些表的文件是一个增量（文件中只有有一些变化的行）
    • 对一条记录的一个属性进行一次更改（同样仅由第 3 方更改）将导致该记录的所有数据都在文件中
  • 代码和名称的域值 未知。

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

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

有什么想法吗？

4

1 回答 1

0

构建原型。进行测量。

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

    主表查找表
    主键 (PK) 代码 (PK)
    代码 (FK) 名称
    其他列

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

    主表
    主键 (PK)
    姓名
    其他列

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

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

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

更多的代码，更差的性能，是的，更多的空间。

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

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

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

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

而且您通常不需要加入即可获得全名；国家代码旨在供人类阅读而无需扩展。

于 2013-07-31T01:40:56.417 回答