gipi的學習筆記-經營管理、數據思考、終身學習

裡頭有針對Force.com的Data model作了一些說明，其實我對這一塊還蠻有興趣的，一般我們在處理資料時，最習慣的用法應該是對資料庫下SQL，但因為每種異質資料來源的查詢語法都不太相同，SQL Server/Oracle/DB2/XML等等的語法都不一樣，如果我們的語法是直接對資料庫下，那一定會面臨支援異質資料庫的問題，最老舊的做法就是直接在程式中寫不一樣的語法，透過設定檔決定目前要跑哪一段，這算是比較老舊的做法，如下：


如果我們希望隔離Application跟Database之間的關聯，以解決要撰寫多種查詢語法的問題，我們可能會透過建構Data Model的方式來實現，讓Application對Data Model進行操作，然後由Data Model轉換成實際的異質資料來源語法，直接對資料來源作操作，LINQ在概念也很類似這種模式。


不過發展這種Model最困難的地方在於，原本的查詢語法千奇百怪，這種千變萬化的語法，我如何在我的Data Model中全都定義清楚，例如有些功能只在SQL Server中支援，在Oracle中不支援，我的Data Model要怎麼處理？這部分必須說，Data Model本身就會有一些基本限制，很難(本來想說不可能，但太武斷)支援全部的語法，可以支援到90%以上的語法已經很了不起了，想起幾年前一個突發奇想([C#] 仿LINQ實作支援異質資料庫來源(未完成))，想透過物件的形式來達成這個功能，後來還是無法實現，探討原因有幾個：
1.對異質資料支援能力與限制不夠熟悉
2.使用了這個Data Model後，Programmer的習慣要整個改變
3.對Performance沒有信心

今天又看到Force.com的Salesforce Object Query Language (SOQL)，發現它也是以操作物件取代直接操作資料庫，開發人員甚至不知道他的資料放在哪種資料庫中，不過SOQL也一如預期，不能支援全部的SQL語法，參考這邊：
How is SOQL different from SQL?

另外也因為Force.com的Data Model並不是一般的RDBMS處理方式，在處理關聯時也跟關聯式資料庫有所差別，可以參考。