从生产中的表中删除列

one*_*ill 8 database-design sql-server

我们有一种情况需要将 2 个表之间的关系从m:1更改为m:n

因此,我们需要在这两个表之间创建一个交叉引用表。

将所有现有数据从“子”表迁移到交叉引用表后,删除子表中的原始外键列是否是一个坏主意?

如果我们把它留在那里,我们基本上就有了技术债务。但我不是 dba 并且不能很好地理解从表中删除列的含义。(我知道这是可能的,但这是一个坏主意吗?我的数据库会因此讨厌我吗?)

谢谢

小智 5

在不了解您表的所有结构的情况下,我的建议有限。但是,不,如果您在以下情况下删除列(绝不是详尽无遗),您的数据库将不会绘制您的死亡图:

  1. 您仍然使用数据库键来映射您的维度。
  2. 您在这个新维度表上的新索引正确地覆盖了索引。
  3. 您管理此数量的索引以免使插入/更新负担过重

你的新设计有二维表和一个事实表

  • 这就是为什么它从 m:1 到 m:n 并带有“交叉引用”表。我们称之为另一个维度。

设计实际上实现了标准化来实现这一点

  • 通过删除依赖项,您的团队将能够更好地检索可以以更有意义的方式改变数据处理方式的事实。

关于尺寸和事实的说明

  • 描述性上下文的维度

维度提供围绕业务流程事件的“谁、什么、在哪里、何时、为什么和如何”上下文。维度表包含 BI 应用程序用于过滤和分组事实的描述性属性。牢记事实表的粒度,可以识别所有可能的维度。

只要有可能,当与给定的事实行相关联时,维度应该是单值的。维度表有时被称为数据仓库的“灵魂”,因为它们包含使 DW/BI 系统能够用于业务分析的入口点和描述性标签。维度表的数据治理和开发投入了不成比例的工作,因为它们是用户 BI 体验的驱动因素。

  • 测量事实

事实是由业务流程事件产生的度量,并且几乎总是数字的。如事实表的grain 所描述的,单个事实表行与测量事件具有一对一的关系。因此,事实表对应于物理可观察事件,而不对应于特定报告需求。在事实表中,只允许与声明的粒度一致的事实。例如,在零售交易中,销售产品的数量及其扩展价格是好的事实,而商店经理的工资是不允许的。

Kimball 维度建模技术

我的建议是设计团队应该知道在数据库中执行规则是最好的,除非它会损害性能。不过,我不知道你的 DDL 语句的大小或量化来完全回答这个问题。

但是请放心,这对您的系统来说应该是一个积极的变化,因为现在 SQL Server 将不必通过所有额外的数据来检索真正重要的内容。


Dan*_*man 5

我知道这是可能的,但这是一个坏主意吗?我的数据库会因此讨厌我吗?

我不能代表你的数据库,但我会讨厌你:-)

旧列将包含更改后的冗余数据。如果旧列和新外部参照表彼此不一致,这可能会导致数据冲突。考虑到不熟悉技术债务的开发人员可能会在逻辑上损坏数据库。

我很难想出一个不应该删除遗留列和关系的原因。这也将确保正确更改所有相关代码。