2

这是一个理论上的问题，由于我最近收到了一个请求，我提出了这个问题。我拥有一个主操作数据存储的支持，它维护一组数据表（带有主数据）以及一组查找表（其中包含参考代码列表及其描述）。最近，下游应用程序推动在表示层中将两种结构（数据和查找值）逻辑地结合起来，以便他们更容易发现整体数据中是否有更新。虽然请求是可以理解的，但我的第一个想法是它应该在接口级别而不是在源头上实现。在 ODS 级别逻辑组合两个表 (last_update_date) 几乎类似于数据的反规范化，并且似乎与保持查找和数据分离的想法相反。就是说，除了它“似乎”不正确的事实之外，我想不出为什么不应该在 ODS 级别完成它的任何原因......有没有人对为什么这种方法应该或不应该有任何想法被跟踪？

为简单起见，我在这里列出一个示例。

Data table
ID    Name    Emp_typ_cd  Last_update_date
1     X       E1          2014-08-01
2     Y       E2          2014-08-01

Code table
Emp_typ_cd     Emp_typ_desc    Last_Update_date
E1             Employee_1      2014-08-23
E2             Employee_2      2013-09-01

下游请求是将数据表示为

Data view
ID    Name    Emp_typ_cd  Last_update_date
1     X       E1          2014-08-23
2     Y       E2          2014-08-01

或者

Data view
ID    Name    Emp_typ_cd  Emp_typ_desc   Last_update_date
1     X       E1          Employee_1     2014-08-23
2     Y       E2          Employee_2     2014-08-01
4

1 回答 1

1

你是对的，它使数据库士气低落，因为有人想以某种方式查看数据。如您所知，副作用是您正在复制数据，降低灵活性，增加表大小，将不同的对象存储在一起等。您也正确的是，他们的问题应该在某个地方或以其他方式解决。如果他们以他们想要的方式改变数据库，他们将不会得到他们想要的东西。如果他们想让“更容易发现整体数据是否有更新”，但他们复制了大量数据，他们只是在向错误敞开大门。在您的示例中，必须为所有具有该 emp 类型代码的员工更新 Emp_typ_cd 更新值。一个好的更新声明会做到这一点，但仍然，

我们一直使用查找表。我们可以向查找表添加一个新值，将员工添加到数据库中，并为该新属性添加一个 fk，并且任何连接到该表的报表现在都具有 ID、值、排序顺序等。假设我们添加了“老兵” ' 到 lu_Work_Experience。我们添加了一个具有资深 fk_Id 的员工，现在任何加入 lu_Work_Experience 的现有查询都具有该值。他们按字母顺序或我们预定义的排序对工作经验进行排序。

不过，扁平化数据结构是有正当理由的，那就是速度。如果您正在运行一个非常大的报告，现在加入（和良好的索引）会更快。如果企业知道它将多次运行一个非常大的报表并且担心最终用户的等待时间，那么为该报表构建一个表是一个好主意。我们一直这样做是为了计算度量。如果我们知道某个分析报告将有大量的聚合和连接，我们会将数据预先聚合到数据存储中。话虽如此，我们在 SQL 中并不经常这样做，因为我们使用多维数据集进行分析。

那么为什么要在数据库中使用查找表呢？数据的逻辑分离。员工有员工代码，但没有员工代码更新的日期。减少重复数据。最大限度地降低设计复杂性。避免为特定报告构建表格，然后必须为不同的报告构建不同的表格，即使它具有相似的数据。

无论如何，我的其余论点将由数据库规范化维基百科页面中的事实组成，因此我将跳过它。

于 2014-09-11T02:41:31.253 回答