物件導向建模與資料表建模兩種分析設計方法的比較的思考

fox0424發表於2008-09-23
物件
不好意思，我又來發布一點不同的聲音了
1、為進一步說明OO和關聯式資料庫是屬於兩個不同世界觀，存在天然矛盾，就象有神論和無神論。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
從本質上兩者是和諧同一的，為什麼這樣說，因為你所有物件的屬性最終分解的結果不會超過計算機固有資料型別，即int，char，byte，double，float等這些基本資料（現在string也算基本資料結構吧）db完整的實現了這些資料結構。而且OO與DB很多地方相似，比如物件的完整性（一個物件必定要有固定的屬性，且要保持資料完整，DB的需要有固定列，而且強調資料完整性），物件的可擴充套件性（物件的繼承，子類比父類多屬性，DB是新的表）。

2、物件和關聯式資料庫累贅轉換
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
這一點我承認，確實是存在一定的麻煩。但是我又仔細想了一下，好像有那裡不對。那裡不對那？？就是物件的序列化問題。網路傳輸，物件儲存，都會要序列化，當然現在說最符合思維而又讓人能夠很容易看懂的最好方法是XML。如果使用COBRA，EJB也許可以不用關心網路傳輸的序列化問題，但是儲存的序列化還是要考慮的。xml最大的優點就是最大的缺點，自我描述的冗餘性。且效率上存在很大的問題，而且需要自己來保證資料的完整性，依然很麻煩。

怎樣解決：
public class Course {
　　public string name;
　　public int courseID;
　　int deptID;
　　public int creditHours;
}
這樣的一個物件對應一個錶行的可以使用反射，增加一個屬性對應資料庫增加列，可以要求名稱具有特定規則即可（Java的規範便是這樣的約束）。
關於人與學生的那個，應該使用多張表來解決。而且現在也是這樣解決的。國內某家銀行，其對公對私客戶是放在一張表中（統稱客戶表），根據對公對私的不同特性會有不同的特性表。從資料庫方向考慮也不推薦放在一個表裡面，會嚴重影響效率。
關於教授與部門的，是採用對映表的方式，代表部門的是部門ID，代表教授的是教授ID（OO也是這樣的，怎樣找到一個物件？？通常我們會透過ID來尋找）

Hibernate只能解決簡單系統的問題，不能解決所有問題，當系統複雜，OR對映時需要自己寫程式碼（OO的序列化也得自己寫，乾脆序列化到DB），而且是否一次性提交那麼多資料，在於你可以適當考慮充血模型（setter裡面只對修改屬性進行記錄，提交時只修改變動屬性相關表）。

綜上所述：DB與OO並不是天生的對頭，而在於你怎樣去看待這兩個工具。


－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
是在是原來的討論貼不讓我回復了，只能新發了，純討論，勿刪貼

相關文章