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 肥仔 阅读(2461) 评论(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 | 杨成

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   博问   Chat2DB   管理