前陣子做個資料庫分析設計,做了相當大膽的事. 因學過UML Class Diagram不久,從現有網站資料反推資料庫模型的事, 就使用Class Diagram處理,覺得構思相當順暢且合理,比E-R model順多了. (其實E-R model是Class Diagram的子集) 但是做了過度抽象化,譬如原網站資料分為好幾個區塊,各區塊有各自的主題訴求, 譬如A區塊發佈新聞,B區塊展示商品,C區塊提供FAQ... 在這裏就看到所有的區塊都屬於一個Class類別, 而所有區塊內容每一條目,都屬於一個Object類別, 由於有些新聞會以合集式刊登,類似於報紙副刊連載小說,同一篇小說分為數回, 所以必須提供一個叢集類別,命名為Cluster. 以連載小說為例,各回的文章都是Object類別實體, 它們歸屬於一個名為novel的Class類別實體, 而同一小說主題的各回篇章,歸屬於一個以該小說主題為名的Cluster類別實例. 同學們聽到這裏有沒有問題? 好,沒有問題,那我們繼續下去. 這樣做完之後,思考這個模型的好壞, 我覺得它有個好處是資料庫的表格少,對寫程式來講,比較好記. 不過因為表格少,每個表格資料累積就會大,資料多一點就會慢...吧? 另外,應用程式的view與資料庫的view差異相當大, (不像一般寫程式的人建資料庫是客戶面要看到什麼表格,資料庫就會建立什麼表格.) 這些差異的地方,就是要靠程式設計才能夠達成的應用程式功能. 其實這樣的差異並不特別, 一般來說,資料庫較底層會有一些程序負責維護實體完整性及參考完整性, 而較高層則會有另一些程序來實現像商業規則(business rule)這樣的應用規則. 關於以上所說明的事,網友們有沒有什麼反方/正方的看法? 請多指教. --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.231.16.89