数据库设计的重要性和设计原则
作者:网络转载 发布时间:[ 2012/10/31 10:14:10 ] 推荐标签:
那么我们要做到什么程度才是对的呢?下面说说数据库设计的原则:
1、数据库设计起码要占用整个项目开发的40%以上的时间
数据库是需求的直观反应和表现,因此设计时必须要切实符合用户的需求,要多次与用户沟通交流来细化需求,将需求中的要求和每一次的变化都要一一体现在数据库的设计当中。如果需求不明确,要分析不确定的因素,设计表时要事先预留出可变通的字段,正所谓“有备无患”。
2、数据库设计不仅仅停留于页面demo的表面
页面内容所需要的字段,在数据库设计中只是一部分,还有系统运转、模块交互、中转数据、表之间的联系等等所需要的字段,因此数据库设计不是简单的基本数据存储,还有逻辑数据存储。
3、数据库设计完成后,项目80%的设计开发在你脑海中已经完成了
每个字段的设计都是有他必要的意义的,你在设计每一个字段的同时,应该已经想清楚程序中如何去运用这些字段,多张表的联系在程序中是如何体现的。换句话说,你完成数据库设计后,程序中所有的实现思路和实现方式在你的脑海中已经考虑过了。如果达不到这种程度,那当进入编码阶段后,才发现要运用的技术或实现的方式数据库无法支持,这时再改动数据库会很麻烦,会造成一系列不可预测的问题。
4、数据库设计时要考虑到效率和优化问题
一开始要分析哪些表会存储较多的数据量,对于数据量较大的表的设计往往是粗粒度的,也会冗余一些必要的字段,已达到尽量用少的表、弱的表关系去存储海量的数据。并且在设计表时,一般都会对主键建立聚集索引,含有大数据量的表更是要建立索引以提供查询性能。对于含有计算、数据交互、统计这类需求时,还要考虑是否有必要采用存储过程。
5、添加必要的(冗余)字段
像“创建时间”、“修改时间”、“备注”、“操作用户IP”和一些用于其他需求(如统计)的字段等,在每张表中必须都要有,不是说只有系统中用到的数据才会存到数据库中,一些冗余字段是为了便于日后维护、分析、拓展而添加的,这点是非常重要的,比如黑客攻击,篡改了数据,我们便可以根据修改时间和操作用户IP来查找定位。
6、设计合理的表关联
若多张表之间的关系复杂,建议采用第三张映射表来关联维护两张表之间的关系,以降低表之间的直接耦合度。若多张表涉及到大数据量的问题,表结构尽量简单,关联也要尽可能避免。
7、设计表时不加主外键等约束性关联,系统编码阶段完成后再添加约束性关联
这样做的目的是有利于团队并行开发,减少编码时所遇到的问题,表之间的关系靠程序来控制。编码完成后再加关联并进行测试。不过也有一些公司的做法是干脆不加表关联。
8、选择合适的主键生成策略
主键生成策略大致可分:int自增长类型(identity、sequence)、手动增长类型(建立单独一张表来维护)、手动维护类型(如userId)、字符串类型(uuid、guid)。int型的优点是使用简单、效率高,但多表之间数据合并时很容易出现问题,手动增长类型和字符串类型能很好解决多表数据合并的问题,但同样也都有缺点:前者的缺点是增加了一次数据库访问来获取主键,并且又多维护一张主键表,增加了复杂度;而后者是非常占用存储空间,且表关联查询的效率低下,索引的效率也不高,跟int类型正好相反。
终上所述,我们可见数据库设计在整个软件开发的起到的举足轻重的作用,尤其是我说的设计原则的第一点,数据库与需求是相辅相成的,我经常把软件开发比作汽车制造。汽车制造会经过图纸设计,模型制作,样车制造,小批量试生产,后是批量生产等步骤。整个过程环环相扣,后一过程是建立在前一过程正确的前提基础之上的。如果在图纸设计阶段发现了一个纰漏,我们可以重新进行图纸设计,如果到了样车制造阶段发现这个错误,那么我们要把从图纸设计到样车制造的阶段重来,越到后面发现设计上的问题,所付出的代价越大,修改的难度也越大。
数据库设计难度其实要比单纯的技术实现的难很多,他充分体现了一个人的全局设计能力和掌控能力,所以在今后的项目中大家一定要着重培养这方面的能力,这里我将我的经验分享给了大家,希望能对大家有所帮助。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11