2012-02-22 64 views
2

我剛剛學習ORM的知識,想知道...如果你有一個對象(一個JSON讓我們說...並假設它是密集的,包含嵌套的對象,具有可能因對象而異的屬性總數對象等),將其簡單地轉換爲序列化數組並將其存儲在表中的參數是什麼?ORM與序列化數組?

我描述的對象可能無法正常化;它會有不確定數量的屬性,這意味着一個不確定的列......將這種東西映射到一個表格需要遍佈整個地方的瘋狂數量的行和鍵。

如果您最終計劃查詢數據庫以便通過代碼進行處理,那麼簡單地序列化它或使用某種類型的OODB有什麼缺點?使用ORM可以獲得什麼?

回答

0

我的經驗是,由於ORM的存儲層希望存儲數據是動態的,因此對其格式沒有任何先入之見,它可以更好地處理例外情況。 (不是實際的錯誤例外,但是您的對象與您的數據庫架構不匹配的情況)

當您處理動態對象時,經典存儲實施的強制通常會強制您將異常處理爲規範或創建數據庫模式如此鬆散,使用它會挫敗通常由數據庫引擎授予的優化;考慮計算的統計數據和各種指數。然而,最終我認爲你已經在第二段中指出了一個問題:如果它不能正常化,那麼你將難以將它表示爲一個足以讓數據庫高效工作的模式。

當然你可以將整個對象序列化到一個數組並存儲它,但是你失去了良好索引,全文搜索的效力,並且能夠交叉引用對象而無需進行多次讀取。

以上示例爲例,假設您的數據庫正在建模電子商務訂單,並且您想要查找後續採購訂單到最初的訂單。數據庫需要知道如何讀取每個序列化的項目以找到它的parentId屬性,然後重新掃描表中的匹配項。

長話短說,ORM是解決現存問題的答案,因爲面向對象的編程是夢寐以求的 - 除非您確信數據結構/模式是僵化的,否則不要擔心並使用它們。對SQL很敏感。

+0

很好的答案!感謝Russ。但是,像MongoDB這樣的東西比在關係數據庫上添加圖層(這不是用於處理對象)更好?一個OOdb行Mongo仍然會給索引和搜索權?再次,我是一個小白菜!請不要拍攝。 :) – 2012-02-22 03:21:08

+0

不,不;你是絕對正確的 - MongoDB/RavenDB/MemcacheDB和其他一些是正確的路! Mongo會給你你需要的索引/搜索。 – 2012-02-22 03:27:51