一點被忽視的模型使用方法

：[@more@]

現在每個公司，每個技術人員再談到BI/DW的時候都談到模型，不管是關係模型還是多維模型，甚至是二者的混合模型，我們很多人都在考慮表（table）的設計，資料的儲存等等問題，這些的確使我們需要考慮的，但是我們卻忽視了一點，我們前臺展現的只是需要的瀏覽資料，而不是你有沒有資料儲存在database中。當然我這樣說，大家都要問了，不儲存資料怎麼展現資料了？是的，我們需要儲存，但是不是任何展現的資料都需要在資料庫中記錄，有的是我們使用case語句轉化過來的，這些轉化後的資料儲存在資料庫中最好。

言歸正傳，我接觸到的很多的資料模型，大多都是直接用表去展現，而較少的使用檢視（view）

變化維也好，正常的維度也好，我們都可以使用檢視，只要檢視的條件不要太多，索引效率較高，我們其實可以選擇檢視的方式，比如我們常用的person，time，product等等，都存在變化維的問題，而且對於同一張表，比如time，在不同的展現或者分析技術上，使用的方式是不一樣的，通常的報表，只需要展現正常的資料，就可以使用簡單的select from的方式，如果我們需要在維度上過濾一些東西，或者按照某種狀態，型別去過濾資料的時候，或者進行一下計算，比如我們常常提到的holiday的問題，我們就需要增加一下表之間的關聯，使用union或者inner link等方式
這樣既不會改變現有的結構，也方便前臺的展現和以後的一些必要的變動和維護，特別是table結構發生變化，我們就有可能需要去做很多的更改，特別是ETL和前臺的應用。

這裡有幾點使我們需要注意的
1：建模的時候，最好有2-3個status和flag的欄位，比如是否有效，是否過期，是否有特別的用法。這樣方便查詢和使用，同時也為將來企業的業務變化，或者存在併購，收購需要整合系統時預留了擴充套件的空間，特別是很多公司，有很多分公司，而很多系統是一個個的上線，比如中國，日本，韓國，新加坡，有可能這幾個國家的原系統都不一樣，而我們實施時，考慮的只是1-2個系統，當要增加新的系統，我們就變得很為難，一旦我們有足夠的status或者flag的欄位，我們就方便透過view去展現我們需要的資料了

2：考慮多種業務的需要，比如sales和HR，logistic等，需要查詢的時間都可能不一樣，有的需要特別標示週末，有的需要按照周統計，有的需要按照特殊的時間，比如月底等等，這些應用有足夠的瞭解，我們的應用就比較得心應手

3：效能的考慮，使用檢視，如果query不是很複雜的話，效能就和table差不多，如果特別複雜的時候，我建議還是有一張臨時表或者專為view服務的表，加一些相應的ETL去處理資料，這個有點像datamart，主要看實際情況，你願意為應用主題建立datamart還是使用view