用冗余抵御数据库结构的变化

       我没做过大型项目,小型项目也才做了2个,就是分享些心法,也不知道对不对,希望大家指点。

       我主要想探讨一下面向对象和关系数据库的阻抗不匹配。

       数据库里各个有关系的表,其实可以合起来的,合起来就是一张表,一张很大很大的含有冗余的表。

       数据库的设计就是把一张大表有冗余的数据变得不冗余,设计数据库的时候,心里要知道那张大表是什么。

       如果数据库里只有一张表的话,操作起来会非常好办,因为表里的每一行,就是一个对象。

       为了不冗余而把大表拆分成为几个小表,那么每个小表里的一行数据的概念就模糊了,它不是一个对象。它无法映射到面向对象里面的一个对象,面向对象是不管冗余的。

       所以在程序里看到的,最好是那张有冗余的大表,而看不到那些小表,当然也不知道大表小表的关系。那么面向对象的味道就出来了,程序不去关心大表怎么拆分成小表的,那张大表就是数据库与面向对象的接口,是稳定的,接口每一行都对应着面向对象里的一个类的对象,即使大表有变化也只是增加列,而结构永远不会变化,因为程序的眼中只有一张表。

       这样的缺点就是牺牲效率,数据不是很多的项目是可以用的。

       面向对象天生就是以牺牲运行效率为代价而使得编码维护方便;关系数据库天生就是为了减少冗余,提高数据库的效率。两者永远会是矛盾,面向对象迁就关系数据库了,编码维护就麻烦些;关系数据库迁就面向对象,运行的效率就低些。小型项目,用牺牲运行效率来抵御变化是可以接受的;大型项目不妨牺牲人力成本来抵御变化好了。

posted on 2008-08-17 12:48 国士无双 阅读(1969) 评论(12)  编辑 收藏 网摘

评论

#1楼 2008-08-17 13:46 金色海洋(jyk)      

1对1 关系的表可以合成一个大表,1对2 的勉强,1对3的就不要勉强了。

当然还要求能够保证1对1、1对2是不会变化的。

1对n的话,就不要和在一起了,很郁闷的。
  回复  引用  查看    

#2楼 2008-08-17 14:39 LuChaoShuai      

一个产品分类表,
一个产品表,

之前产品表里面只有一个产品分类的ID引用,现在产品表里面有产品分类的其它信息,就可以把产品分类表去除了。

这个设计。。。。不好说。

要是我有1000个产品对应一个产品分类,我想改变一个产品分类的名字,那不是.......
  回复  引用  查看    

#3楼 2008-08-17 14:59 水言木      

个人认为,如果这样倒不如去用面向对象数据库。把关系型数据库拿来这么折腾,有点心疼~~   回复  引用  查看    

#4楼 2008-08-17 16:04 hack      

学习。。   回复  引用  查看    

#5楼[楼主] 2008-08-17 16:45 国士无双      

呵呵,我的意思是关系数据库里的还是多张表,在程序里先用sql语句把有关系的多张表拚成一张大表。或者说用视图也成。   回复  引用  查看    

#6楼 2008-08-17 17:25 亚历山大同志      

--引用--------------------------------------------------
国士无双: 呵呵,我的意思是关系数据库里的还是多张表,在程序里先用sql语句把有关系的多张表拚成一张大表。或者说用视图也成。
--------------------------------------------------------
那不是和share point存储数据的方式差不多咯哇?
  回复  引用  查看    

#7楼 2008-08-17 19:08 Kai.Ma      

用视图的想法不错,推荐用索引视图   回复  引用  查看    

#8楼 2008-08-17 19:13 阿牛 - 专注Web开发      

OO和DB中的矛盾是我们程序员心中永远的痛!   回复  引用  查看    

#9楼 2008-08-18 10:44 涵舍愚人      

数据量大的时候,是否牺牲太大了?   回复  引用  查看    

#10楼 2008-08-18 10:55 Ivony...      

设计是用来使用的,不是用来应对变更的。为了应付变更而牺牲正常使用是舍本求末的做法。   回复  引用  查看    

#11楼[楼主] 2008-08-18 11:18 国士无双      

--引用--------------------------------------------------
Ivony...: 设计是用来使用的,不是用来应对变更的。为了应付变更而牺牲正常使用是舍本求末的做法。
--------------------------------------------------------
呵呵,是为了抵御需求的不确定性。如果需求不会变,什么设计模式也不要了。
  回复  引用  查看    

#12楼 2008-08-18 12:43 Ivony...      

--引用--------------------------------------------------
国士无双: --引用--------------------------------------------------
Ivony...: 设计是用来使用的,不是用来应对变更的。为了应付变更而牺牲正常使用是舍本求末的做法。
--------------------------------------------------------
呵呵,是为了抵御需求的不确定性。如果需求不会变,什么设计模式也不要了。
--------------------------------------------------------


设计是编码的基础,如果不用设计,数据库与代码,UI与逻辑如何契合?如果不设计数据结构,查询如何实现?把所有数据都加载到内存然后慢慢筛?
  回复  引用  查看    

发表评论

昵称: [登录] [注册]

主页:

邮箱:(仅博主可见)

评论内容:

  登录  注册

[使用Ctrl+Enter键快速提交评论]

0 1269717




相关文章:

相关链接:

导航

<2008年8月>
272829303112
3456789
10111213141516
17181920212223
24252627282930
31123456

统计

与我联系

搜索

 

常用链接

留言簿

我参加的小组

我的标签

随笔档案

最新评论