• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            woaidongmao

            文章均收錄自他人博客,但不喜標題前加-[轉貼],因其丑陋,見諒!~
            隨筆 - 1469, 文章 - 0, 評論 - 661, 引用 - 0
            數據加載中……

            淺層數據結構(結構型)vs 深層數據結構(聚合型)

             

            構建系統數據模型時,有2共選擇,以:group->account->son account舉例

            1、系統由多個group組成;

            2、一個group有多個account;

            3、一個account有多個son account.

             

            有2種數據模型構建方式選擇;

            image

            1、模式一的數據模型由3張表構成:groups表,accounts表,son accounts表。是淺層數據結構(結構型),每張表的深度是1。accounts表將有一個[group]字段關聯到groups表里面的某條記錄;son accounts表將有一個[account]字段關聯到accounts表里面的某條記錄。可以說這是一種經典的數據結構,結構型數據庫就是由這樣深度為1的二維型數據表構成,多張表之間的關系通過增加關聯字段來標明;

            2、模式二的數據模型中,把group視作一個整體,它是數據層的一個基本單元(unit),數據層由多個group對象組成,group對象的深度是3,是深層數據結構(聚合型)。現實的模型對應為對象型數據庫;

             

            現在的問題是:模式一簡單還是模式二簡單?哪一種是更為優越的選擇?我傾向于模式一,因為:

            1、結構型數據建模是經典的,目前依然是主流的,得到數據庫的廣泛支持,即使不使用數據庫,也容易序列化到存儲,并且我相信群眾,相信主流意志的正確性;

            2、模式二的對象型數據建模,group是數據元,是數據操作的唯一入口,所以需要提供account,son account的操作接口,account又需要提供son account的操作接口,假設對象深度再多增加幾層,那這是一個龐大且累贅的冗余。另外一點是樹形的對象不容易序列化,沒有太多數據庫支持;

            3、模式二的層次太深,復雜度級數上升,違反了系統弱化成小類模型的原則(多個類,每個類的復雜度都很低),而這里,group將是一個很大的類。

            4、第一感覺:模式一的復雜度我能控制,模式二就沒有把握,所以心里更認同模式一;

            5、雖然模式二直觀的表明了數據的聚合-組合關系,與現實模型完全隱射,在理論上應該是更好的選擇。但是就人的理解能力的傾向來說:我認為理解廣度的事務比較理解深度的事務而言更有優勢;

            6、寫到這里,我突然想說一句:化深度為廣度,符合人的認知規律,降低了復雜度。

            posted on 2008-10-25 02:36 肥仔 閱讀(2512) 評論(5)  編輯 收藏 引用 所屬分類: 編程思想

            評論

            # re: 淺層數據結構(結構型)vs 深層數據結構(聚合型)  回復  更多評論   

            現在很多都是采用聚合型。
            2008-10-25 16:46 | 金山詞霸2008

            # re: 淺層數據結構(結構型)vs 深層數據結構(聚合型)  回復  更多評論   

            兩邊的account根本就不一樣
            模式一的account是list<account>
            右邊的account才真的是account

            左邊的圖你沒有確保一個sub account只能被一個account擁有,會導致后續開發出錯的可能性增大。
            2008-10-27 13:15 | 陳梓瀚(vczh)

            # re: 淺層數據結構(結構型)vs 深層數據結構(聚合型)  回復  更多評論   

            @陳梓瀚(vczh)
            模式二確實很OOP,不過我接觸過的項目,基本上是用關聯來替代聚合,我的經歷也告訴我,模式一更為簡單,更容易控制。

            模式二看上去很美,卻膠合層太厚重,冗余的接口帶來負擔,要變通也困難。
            聚合的本質就是一種強耦合,看上去漂亮而已吧。
            2008-10-27 16:05 | 肥仔

            # re: 淺層數據結構(結構型)vs 深層數據結構(聚合型)  回復  更多評論   

            測試一下回復功能。
            2008-12-20 22:02 | 楊成

            # re: 淺層數據結構(結構型)vs 深層數據結構(聚合型)  回復  更多評論   

            gourp -> accounts -> son accounts 的概念太抽象,我們具體點,
            很簡單的,比如汽車是一個group,
            那么不同品牌的汽車算是各個accounts,不同品牌的汽車的不同型號算是son accounts。

            如果是模式1,那么我們就需要歸納,每個品牌都有哪些字段,以便區分各個品牌。
            每個型號汽車都有哪些字段,區分各個型號。我們將有3個類,每個類都有若干字段。因為型號特別多,每個型號或許都有自己特有的字段,但是因為是統一的類,因此,所有型號字段都是一樣的,可能默認值不同。那么這樣一個扁平的數據結構里,各種算法交錯,各種變量之間也是高度耦合。在這種情況下,一旦增加一個新車型,要有自己特定的新字段,那么所有的邏輯和代碼都要修改。

            如果是模式2,每個品牌是自己特有的類,每個型號也是自己特有的類,有一些公共的接口,將來增加新的品牌,新的型號只是增加類的種類而已,以前的代碼是不需要動的。這也是oo的最大好處。

            認為模式1比模式2好的人,或許等同于認同c比c++好很多。而且上面有的評論,說什么關聯和聚合,聚合是相對于包容模型很而言把,跟關聯沒什么關系啊。
            2008-12-20 22:18 | 楊成
            国产99久久久久久免费看| 精品熟女少妇a∨免费久久| 久久精品综合一区二区三区| 国产精品欧美亚洲韩国日本久久 | 久久受www免费人成_看片中文| 久久伊人色| 精品熟女少妇av免费久久| 日韩精品久久久久久| 无码任你躁久久久久久老妇App| 亚洲AV无码久久精品成人| 国产农村妇女毛片精品久久| 超级碰碰碰碰97久久久久| 成人妇女免费播放久久久| 亚洲伊人久久成综合人影院| 国产精品久久久久久久久| 久久国内免费视频| 久久国产成人精品国产成人亚洲| 伊人久久大香线焦AV综合影院 | 国内精品久久久久影院网站| 久久香综合精品久久伊人| 亚洲国产天堂久久综合网站 | 久久亚洲国产中v天仙www| 亚洲精品高清一二区久久| 88久久精品无码一区二区毛片| 婷婷综合久久中文字幕蜜桃三电影| 久久精品成人欧美大片| 久久亚洲欧美日本精品| www.久久热.com| 国产亚洲婷婷香蕉久久精品| 久久99精品久久只有精品| 亚洲精品乱码久久久久久蜜桃不卡 | 久久久久久av无码免费看大片| 人妻少妇久久中文字幕一区二区| 99久久国产亚洲综合精品| 欧美一级久久久久久久大| 美女久久久久久| 日产精品久久久久久久| 狠狠色婷婷久久综合频道日韩 | 97久久综合精品久久久综合| 性欧美丰满熟妇XXXX性久久久 | 国产精品成人无码久久久久久|