目前整個行業(yè)通常的模型治理方法，是規(guī)定一種建模規(guī)范，大家在編碼的過程中各自遵守。

當(dāng)業(yè)務(wù)開始變得模糊不清的時候，再專門抽調(diào)時間，來做人工治理。就像黃河一樣，流沙清理了一次又一次，但上游還是會沖下新的流沙。

?

數(shù)倉的假設(shè)既然都是采用的維度建模，那么其設(shè)計思想必然是自下而上的進(jìn)行建設(shè)，與架構(gòu)進(jìn)行類比，也就是先做好子模塊，最后做頂層設(shè)計。
但如果設(shè)計者不熟悉對應(yīng)的領(lǐng)域模型，一旦業(yè)務(wù)上發(fā)生了變動，一張核心表動輒幾百張的引用，會讓重構(gòu)的工作變得困難無比。
比如模型的健康分，看看你的存儲成本有多少、計算成本有多少、生命周期是不是合理、代碼規(guī)范有沒有避免全表掃描，等等。但這些工作只能發(fā)現(xiàn)一些常規(guī)的問題，也依然需要進(jìn)行人工治理，不僅效率上沒有得到提高，每天推送的郵件也會讓你產(chǎn)生心煩。
投入多少人，投入多少時間，終歸是解決了一時的問題，而非長遠(yuǎn)。

因此，換個思路考慮問題，當(dāng)業(yè)務(wù)高速發(fā)展時，數(shù)倉勢必要跟著跑，不然業(yè)務(wù)都跪了，數(shù)倉又有何用。但業(yè)務(wù)通常不會一直處于高速發(fā)展的階段，就像長跑一樣，總有跑跑停停的時候，因此如果我們遵循一定的做事方法，流程上多一點步驟，那么就會極大的延緩數(shù)倉治理的問題。
即不追求長久的問題解決，而以一段時間內(nèi)的穩(wěn)定為目標(biāo)，比如一年。當(dāng)業(yè)務(wù)已經(jīng)發(fā)展到比較穩(wěn)定的階段，再回過頭來做治理，既能夠避免因為業(yè)務(wù)變動而影響模型重構(gòu)，也可以節(jié)省大家的精力和壓力，就不失為一種解決思路了。
完美的解決方案通常不存在，退而求其次是大多數(shù)人的選擇。當(dāng)技術(shù)無法解決問題時，不妨用另類思路去解決。