从生产中的表中删除列

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

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

将所有现有数据从“子”表迁移到交叉引用表后，删除子表中的原始外键列不是一个好主意吗？

如果我们把它留在那儿，基本上就是技术债务。但是我不是dba，也不太了解从表中删除列的含义。（我知道这是可能的，但这是一个坏主意吗？我的数据库会为此讨厌我吗？）

谢谢

在不了解表的所有结构的情况下，我的建议有限。但是，不可以，如果在以下情况下删除列（绝不是详尽无遗），则数据库将不计您的灭亡：

1. 您仍然使用数据库密钥来映射尺寸。
2. 您在此新Dimension表上的新索引将正确覆盖应该包含的索引。
3. 您可以管理此数量的索引，以免增加插入/更新的负担

您的新设计具有二维表和事实表

• 这就是为什么它使用“交叉参考”表从m：1变为m：n的原因。我们称此为另一个维度。

设计实际实现了规范化以实现这一目标

• 通过消除依赖关系，您的团队将可以更好地检索事实，从而可以更有意义的方式改变数据的处理方式。

关于尺寸和事实的注释

• 描述性上下文的维度

维度提供围绕业务流程事件的“谁，什么，何时，何地，为什么以及如何”上下文。维度表包含BI应用程序用于过滤和分组事实的描述性属性。牢记事实表的细节，可以确定所有可能的尺寸。

只要有可能，将维与给定的事实行关联时应为单值。尺寸表有时被称为数据仓库的“灵魂”，因为它们包含入口点和描述性标签，这些标签使DW / BI系统可以用于业务分析。由于维度表是用户BI体验的驱动力，因此在数据治理和维度表的开发中要花费大量的精力。

• 测量事实

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

Kimball尺寸建模技术

我的建议是设计团队应该知道，在数据库中强制执行规则是最好的，除非这样做会损害性能。但是，我不知道您的DDL语句的大小或量化程度可以完全回答这个问题。

但是请放心，这对您的系统应该是一个积极的变化，因为现在SQL Server不必再处理所有额外的数据来检索实际重要的内容。

我知道有可能，但这是个坏主意吗？我的数据库会讨厌我吗？

我不能代表您的数据库，但我讨厌您：-)

更改后，旧列将包含冗余数据。如果旧列和新外部参照表之间的维护不一致，则可能导致数据冲突。考虑不熟悉技术债务的开发人员可能会在逻辑上破坏数据库。

我很难想到为什么不应该删除旧列和关系的原因。这还将确保正确更改所有从属代码。