在本月,他们可以根据需要随时陈述和重述价值.在一个月的最后10天,他们会重述数字 – >运行ETL处理 – >每天多次审核报告.月份完成后,书籍将被密封,无法修改数值.

令人惊讶的是,金融服务公司产生了多少财务数据……我们在测试数据集中没有意识到的一点是,数据量将使他们的月末程序难以为继.在用新试运行取代之前,删除“当月的数据”花了相当长的时间.

我们必须做一些事情来使处理更快,而不会破坏未知的“谁知道什么”列表,这些列表都取决于MonthlyAllocation表.我决定扮演魔术师并从桌面下面鞭打桌布.我去了老派并使用了Partitioned View.数据已经有一个IsComplete标志,所以我制作了两个表 – 每个表都有相反的检查约束：MonthlyAllocationComplete,MonthlyAllocationInComplete

然后,我创建了与原始表名称相同的分区视图：MonthlyAllocation.对于我们对数据库进行的物理更改,没有任何流程更明智.没有报告被破坏,没有一个直接访问的分析师报告了之前或之后该“表”的任何问题.

很酷的故事兄弟,但你要去哪里？

如果他们有一个命名约定,tbl_MonthlyAllocation怎么办？怎么办？我们是否花费大量的工时来处理每个ETL,每个报告,组织中的每个临时电子表格并更新它们以使用vw_MonthlyAllocation？当然,所有这些变化都要经过变革委员会,这一直是一个快速而无痛的过程.

你的老板可能会问：对于所有这项工作,公司的回报是什么？

另一个选项变为我们将此视图命名为tbl_,而不是花费所有时间来测试,更新和部署代码.这成为一个有趣的轶事,你解释给所有新员工,以及那些注意力短暂的人,必须与数据库合作,为什么你与对象的命名不一致

或者,不要使用冗余元数据对对象进行双重编码.数据库很乐意告诉你什么是表,什么是视图,什么是表值函数等.

命名约定很好,只是不要把自己描绘成一个角落.