資料倉儲的規模越大，元資料就越能體現出它的作用。就像一本書，如果內容不多，有無目錄像響不大，
如果厚達幾百頁而又沒有目錄，頁碼，那麼使用這本書簡直是受罪。
日常生活也是如此，到處是元資料帶給我們的便利。想想我們去圖書館，音像店，甚至是餐館點菜的菜譜。。。
etl方面，元資料一樣重要。有些公司在一開始就依賴工具。這樣入口統一，規則也統一，所以元資料收集比較方便，準確。
也有一些公司是先coding的方式，這在幾年前比較常見。由於那時候公司管理者還不知道資料倉儲能帶來的價值，
往往是抱著先試試看的態度。而coding的優點就是靈活，效率高，前期投入少。
往往經過n年的發展後，問題也會出來，尤其是在一些業務高速發展的公司。後期會變得維護困難，維護的成本很大。
而且小組成員越來越多，coding風格不一，隨意性較大，互相維護起來更不易。
這時候，就需要一次徹底整理。從底層幾十萬行**中，提煉出核心的步驟，
比如a、模組間的排程關係，可以直觀知道乙個模組是放在哪個模組排程的，那個模組的源頭又有哪些模組。
b、表與表間的轉換關係，乙個事實表，它是由哪些事實表計算得來的。又有哪些表是依賴它生成的。
再細下去可到字段級別。如a表的b欄位，是從c表的d欄位，經過sum()得來的。
但個人覺得，要實現字段級別，前提是已經存在較嚴格的編碼規範並嚴格遵守。否則，想實現這個難度還是很高的，
除非你是想手工一行行的整理，那就沒有難度可言，只是時間問題。
但，不管難度怎麼樣，要花多少時間，一旦成功做出來，效果將是非常可喜的，你也一定會覺得很值得。
關於元資料的理解
元資料 metadata 官方定義 是描述其它資料的資料 data about other data 或者說是用於提供某種資源的有關資訊的結構資料 structured data 覺得定義很抽象，我直接for example 這是artist表，有兩個屬性 artistid，name 這是元資料，也...
關於hession 隨筆
今天遇到乙個問題，糾結了很久也沒有解決，情況是這樣的，我這個專案使用的是 hession 通訊。我做的業務很簡單，只是新加了乙個介面 這 個介面是廣告那一塊的，資料庫在之前的專案裡面都沒有使用到addb，所以需要在spring的配置裡面新增addb jdbc.xml 總結 在這樣的專案中，遇到這樣的...
MySQL資料庫 關於查詢 隨筆
select id,title,haha mark from course select from select from relation temp left join audio audio on audio.id temp.audio id order by temp.id desc批量更新條...