共享資料庫 • 企業整合模式

脈絡：一家企業有多套獨立建造的應用程式，使用不同的語言與平台。企業需要資訊被快速且一致地共享。

檔案傳輸不夠的地方#

檔案傳輸讓應用程式能共享資料，卻缺乏時效性——而整合的時效往往是關鍵議題。變更若不能快速穿過整個應用程式家族，你就很可能因為資料陳舊而做錯事。對現代企業而言，讓每個人盡可能拿到最新資料不只減少錯誤，也提高人們對資料的信任。

快速更新也讓不一致更好處理：同步得愈頻繁，出現不一致的機率愈低，處理起來也愈省力。

但無論多快，問題仍在。若某個地址在極短時間內被前後不一致地更新，我要怎麼判斷哪個才是真的？我可以規定「每項資料由某個應用程式擔任主來源」，但接著我就得記住誰是哪份資料的主人。

檔案傳輸也可能無法充分約束資料格式。整合的許多問題，源自看待資料的方式不相容，而這些往往代表著影響巨大的微妙業務議題。

一個地質資料庫可能把「油井」定義為單一個鑽孔（未必產油），生產資料庫卻可能把「井」定義為由單一組設備覆蓋的多個鑽孔。
這類**語意不一致（semantic dissonance）**比資料格式不一致難處理得多。（想深入了解這些議題，非常值得一讀 Data and Reality [Kent]。）

我們需要的是一個集中的、經各方同意的資料存放處，讓所有應用程式共享，任何一方隨時都能存取任何共享資料。

一致性有保障——一整批被整合的應用程式若都依賴同一個資料庫，你可以相當確定它們隨時都是一致的。即使不同來源同時更新同一份資料，交易管理系統也能以目前所能達到的最優雅方式處理；而且因為更新之間的時間極短，任何錯誤都更容易被找到與修正。
SQL 讓它容易得多——基於 SQL 的關聯式資料庫如此普及，幾乎所有應用開發平台都能操作 SQL，工具也相當成熟。你不必煩惱多種檔案格式；而且既然應用程式反正都得用 SQL，也就不必再多學一項技術。
逼你正面處理語意不一致——因為大家用同一個資料庫，語意衝突會被逼出來。這些問題不會潛伏到日後難以用轉換解決，而是被迫在軟體上線、累積大量不相容資料之前就面對並解決。

設計統一 schema 極其困難——要生出一份能滿足多套應用程式需求的統一 schema 是非常艱難的工程，結果常常是一份讓應用程式設計師覺得難用的 schema。
政治困難不亞於技術困難——若某個關鍵應用程式為了配合統一 schema 而可能延期，要求「切出去自己做」的壓力往往無法抵擋，而部門之間的人際衝突常讓問題雪上加霜。
外部套裝軟體是更硬的天花板——它們常常只認自己的 schema；即使有調整空間，也遠比整合人員希望的有限。這個問題也延伸到開發之後：即使你能安排好自家所有應用程式，一旦發生公司合併，整合問題依然存在。

多套應用程式透過共享資料庫頻繁讀寫同一份資料，會造成效能瓶頸，甚至因為互相鎖住資料而產生死結。
當應用程式分散在多台電腦上時，資料庫也必須分散，好讓每個應用程式都能就近存取——而這又讓「資料到底該存在哪台電腦上」變得混亂。一個帶著鎖定衝突的分散式資料庫，很容易變成效能惡夢。