我曾经有一张表，它又亮又漂亮。它拥有一个组织的所有财务交易。然后我们开始将数据加载到其中。

在当前月份，他们可以根据需要随时声明和重述价值。在一个月的最后 10 天，他们会重述数字 -> 运行 ETL 处理 -> 每天多次查看报告。一旦月份完成，账簿就会被封存，无法修改值。

一家金融服务公司生成的财务数据之多令人惊讶……我们没有意识到我们的测试数据集的数据量将使他们的月末程序站不住脚。在用新的试运行替换之前，删除“当前月份的数据”需要花费越来越长的时间。

我们必须做一些事情来加快处理速度，而不会破坏完全依赖于 MonthlyAllocation 表的“谁知道什么”的未编目列表。我决定扮演魔术师，把桌布从他们下面抽出来。我去了老学校并使用了Partitioned View。数据已经有一个 IsComplete 标志，所以我制作了两个表 - 每个表都有相反的检查约束：MonthlyAllocationComplete、MonthlyAllocationInComplete

然后，我创建了与原始表同名的分区视图：MonthlyAllocation。对于我们对数据库所做的物理更改，没有任何流程比这更明智。没有报告发生，没有直接访问的分析师在之前或之后报告该“表”的任何问题。

很酷的故事兄弟，但你要去哪里？
如果他们在那里有一个命名约定，tbl_MonthlyAllocation 怎么办？怎么办？我们是否花费大量工时来检查组织中的每个 ETL、每个报告、每个临时电子表格并更新它们以使用 vw_MonthlyAllocation？当然，所有这些变更都会通过变更委员会，这始终是一个快速而轻松的过程。

你老板可能会问：公司又做了这么多工作有什么回报？

另一种选择是我们将这个视图命名为 tbl_，而不是花费所有时间测试、更新和部署代码。这变成了一个有趣的轶事，你向所有新员工解释，以及那些注意力不集中的人，他们必须使用数据库来解释为什么你与对象的命名不一致

或者您不会使用冗余元数据对对象进行双重编码。数据库会很高兴地告诉你什么是表，什么是视图，什么是表值函数等。

命名约定很好，只是不要把自己画到角落里。