MyException - 我的异常网
当前位置:我的异常网» J2SE » java数据库设计中的14个技艺

java数据库设计中的14个技艺(2)

www.MyException.Cn  网友分享于:2013-12-08  浏览:155次

   
  (1) 一个数据库中表的个数越少越好。只有表的个数少了,才能说明系统的E--R图少而精,去掉了重复的多余的实体,形成了对客观世界的高度抽象,进行了系统的数据集成,防止了打补丁式的设计;
    
  (2) 一个表中组合主键的字段个数越少越好。因为主键的作用,一是建主键索引,二是做为子表的外键,所以组合主键的字段个数少了,不仅节省了运行时间,而且节省了索引存储空间;
    
  (3) 一个表中的字段个数越少越好。只有字段的个数少了,才能说明在系统中不存在数据重复,且很少有数据冗余,更重要的是督促读者学会“列变行”,这样就防止了将子表中的字段拉入到主表中去,在主表中留下许多空余的字段。所谓“列变行”,就是将主表中的一部分内容拉出去,另外单独建一个子表。这个方法很简单,有的人就是不习惯、不采纳、不执行。
  
  数据库设计的实用原则是:在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体概念,综合观点,不能孤立某一个原则。该原则是相对的,不是绝对的。“三多”原则肯定是错误的。试想:若覆盖系统同样的功能,一百个实体(共一千个属性) 的E--R图,肯定比二百个实体(共二千个属性) 的E--R图,要好得多。
  
  提倡“三少”原则,是叫读者学会利用数据库设计技术进行系统的数据集成。数据集成的步骤是将文件系统集成为应用数据库,将应用数据库集成为主题数据库,将主题数据库集成为全局综合数据库。集成的程度越高,数据共享性就越强,信息孤岛现象就越少,整个企业信息系统的全局E?R图中实体的个数、主键的个数、属性的个数就会越少。
  
  提倡“三少”原则的目的,是防止读者利用打补丁技术,不断地对数据库进行增删改,使企业数据库变成了随意设计数据库表的“垃圾堆”,或数据库表的“大杂院”,最后造成数据库中的基本表、代码表、中间表、临时表杂乱无章,不计其数,导致企事业单位的信息系统无法维护而瘫痪。
   
  “三多”原则任何人都可以做到,该原则是“打补丁方法”设计数据库的歪理学说。“三少”原则是少而精的原则,它要求有较高的数据库设计技巧与艺术,不是任何人都能做到的,因为该原则是杜绝用“打补丁方法”设计数据库的理论依据。

  14. 提高数据库运行效率的办法
  
  在给定的系统硬件和系统软件条件下,提高数据库系统的运行效率的办法是:
  (1) 在数据库物理设计时,降低范式,增加冗余, 少用触发器, 多用存储过程。
   
  (2) 当计算非常复杂、而且记录条数非常巨大时(例如一千万条),复杂计算要先在数据库外面,以文件系统方式用C++语言计算处理完成之后,最后才入库追加到表中去。这是电信计费系统设计的经验。
  
  (3) 发现某个表的记录太多,例如超过一千万条,则要对该表进行水平分割。水平分割的做法是,以该表主键PK的某个值为界线,将该表的记录水平分割为两个表。若发现某个表的字段太多,例如超过八十个,则垂直分割该表,将原来的一个表分解为两个表。
  
  (4) 对数据库管理系统DBMS进行系统优化,即优化各种系统参数,如缓冲区个数。
  
  (5) 在使用面向数据的SQL语言进行程序设计时,尽量采取优化算法。
 
  总之,要提高数据库的运行效率,必须从数据库系统级优化、数据库设计级优化、程序实现级优化,这三个层次上同时下功夫。 



------解决方案--------------------
好帖,mark
------解决方案--------------------
收藏, 
对于 5. 通俗地理解三个范式
我个人感觉, 其实在有些大型的系统, 如果查询的频率相对较高的话, 一般只要到2NF时就可以用了, 这样减少了连接查询所带来的系统开销,也可以降低查询语句的复杂度
------解决方案--------------------
探讨
5. 通俗地理解三个范式
  
通俗地理解三个范式,对于数据库设计大有好处。在数据库设计中,为了更好地应用三个范式,就必须通俗地理解三个范式(通俗地理解是够用的理解,并不是最科学最准确的理解):
  
第一范式:1NF是对属性的原子性约束,要求属性具有原子性,不可再分解;
   第二范式:2NF是对记录的惟一性约束,要求记录有惟一标识,即实体的惟一性;
   第三范式:3NF是对字段冗余性的约束,即任何字段不能由其他字段派生出来,它要求字段没有冗余.
  
没有冗余的数据库设计可以做到。但是,没有冗余的数据库未必是最好的数据库,有时为了提高运行效率,就必须降低范式标准,适当保留冗余数据。具体做法是:在概念数据模型设计时遵守第三范式,降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段,允许冗余。


------解决方案--------------------
同样啊,我感觉楼主一定是个数据库设计高手,这要是没有很多经验是做不到的!!
我啥时候才能达到楼主的地步呢?
本人要好好体会楼主共享出来的知识!!
我们应该学习楼主这样的精神!把好东西与大家分享啊!!
前面的路还很长啊!要好好学习您的经验!!
------解决方案--------------------
以下是我前段时间总结的,欢迎批评指正.

数据库设计的5种常见关系,其中本文主要讲“多态”关系结构,以手机为例。

1,配置关系 --和其他表无任何关系的表。
例如:类似webConfig里的东西你存储到表里。

2,一对多关系 ,一张表包含另外一个表的主键作为外键,经常用于分类。
例如:手机.品牌id=2, 这里的2是[品牌名称表]的id字段为2的纪录,品牌名称是"Nokia""Moto" 。一个手机只能有一个品牌。
 
“一对一”是“一对多”关系的一种冗余手段,是有一定历史原因才这样设计的,例如:用户表和VIP用户表,专家表,企业用户表,内部编辑开发人员表虽然都是同样继承用户表的UserID,但是根据网站运营发展,VIP,,专家,企业用户具有很多普通用户不具备的属性和分组规则,这种设计模式上最典型的继承,就可以分表处理,如果不分表就会造成用户表过分冗余,逻辑过分复杂。

3,多对多,至少需要3张表,有一个包含两个外键的关系表,常见用途如下:
1,交叉分组。
例如: 手机1即属于"智能" 又属于"滑盖"组的, 一个组包含多个手机,一个手机可以属于多个组。
2,交叉指定。
例如:手机型号表Model和用户表User,中间需要建立一个(ModelId,UserID),来表明用户是使用哪个型号的手机,可以查到张三用Nokia N95,李四用Moto 1200,这个就是具体用户手机型号的表. 
复杂情况下交叉指定可能会存在一个关系表多个外键的情况,例如:当一个用户有多个手机,想知道他在不同场合(工作,家人)用什么手机,可以给上面的表再增加一个场合用途外键(UserId,ModelId,UsageId)来记录.因为场合和手机也是多对多的交叉关系,这些外键的目的都是为了交叉指定一个具体的多对多实例属性. 


4,树型结构,常见的两钟:父ID设计和001002编码设计。
例如:手机的经销商分为 省/市/县 ,树型无限分类菜单等.
对于无限分级,我主张001002编码设计,因为这接近于哈希算法的原理,可以容易查找子类父类,不需要递归.

文章评论

软件开发程序错误异常ExceptionCopyright © 2009-2015 MyException 版权所有