• <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 肥仔 閱讀(2513) 評論(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 | 楊成
            久久偷看各类wc女厕嘘嘘| 久久精品无码一区二区三区日韩 | 久久精品桃花综合| 精品久久久久久无码人妻热| 欧美黑人又粗又大久久久| 久久亚洲AV成人无码| 色综合久久天天综线观看| 久久久精品波多野结衣| 国产综合免费精品久久久| 国产精品热久久毛片| 大美女久久久久久j久久| 久久99精品国产| 色综合久久88色综合天天| 青青青青久久精品国产| 国产无套内射久久久国产| 久久精品国产亚洲精品| 无夜精品久久久久久| 久久伊人五月丁香狠狠色| 久久狠狠爱亚洲综合影院| 亚洲欧美伊人久久综合一区二区 | 久久精品www人人爽人人| 九九久久自然熟的香蕉图片| 久久国产亚洲精品无码| 国产成人精品久久二区二区| 久久99热国产这有精品| 久久久WWW成人| 久久99热这里只有精品国产| 亚洲AV无码久久精品成人| 69SEX久久精品国产麻豆| 韩国三级中文字幕hd久久精品| 久久天天躁狠狠躁夜夜2020老熟妇| 精品久久久久久久国产潘金莲| 久久无码人妻一区二区三区 | 久久青青草视频| 久久国产精品77777| 久久国产精品免费一区| 无码人妻久久一区二区三区免费 | 久久久久人妻一区精品果冻| 人妻无码αv中文字幕久久 | 伊人久久综合无码成人网| 91精品无码久久久久久五月天|