数据库设计技巧汇总.docx

数据库设计技巧汇总 1)理解客户需求,询问用户如何看待未来需求变化。让客户解释其需求,而且随着开发的继续,还要经常询问客户保证其需求仍然在开发的目的之中。 2)了解企业业务可以在以后的开发阶段节约大量的时间。 3)重视输入输出。在定义数据库表和字段需求时,首先应检查现有的或者已经设计出的报表、查询和视图以决定为了支持这些输出哪些是必要的表和字段。举例:假如客户需要一个报表按照邮政编码排序、分段和求和,你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。 4)创建数据字典和ER图表 ER图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用,而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL表达式的文档化来说这是完全必要的。 5)定义标准的对象命名规范数据库各种对象的命名必须规范。表设计原则 1)标准化和规范化数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式,但ThirdNormalForm通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说,遵守3NF标准的数据库的表设计原则是:“OneFactinOnePlace”即某个表只包括其本身基本的属性,当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点:有一组表专门存放通过键连接起来的关联数据。举例:某个存放客户及其有关定单的3NF数据库就可能有两个表:Customer和Order。Order表不包含定单关联客户的任何信息,但表内会存放一个键值,该键指向Customer表里包含该客户信息的那一行。事实上,为了效率的缘故,对表不进行标准化有时也是必要的。 2)数据驱动采用数据驱动而非硬编码的方式,许多策略变更和维护都会方便得多,大大增强系统的灵活性和扩展性。举例,假如用户界面要访问外部数据源,不妨把相应的连接和路径信息存储在用户界面支持表里。还有,如果用户界面执行工作流之类的任务,那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上,如果过程是数据驱动的,你就可以把相当大的责任推给用户,由用户来维护自己的工作流过程。 3)考虑各种变化在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。举例,姓氏就是如此。所以,在建立系统存储客户信息时,在单独的一个数据表里存储姓氏字段,而且还附加起始日和终止日等字段,这样就可以跟踪这一数据条目的变化。字段设计原则 4)每个表中都应该添加的3个有用的字段 dRecordCreationDate,在VB下默认是Now(),而在SQLServer下默认为GETDATE() sRecordCreator,在SQLServer下默认为NOTNULLDEFAULTUSER nRecordVersion,记录的版本标记;有助于准确说明记录中出现null数据或者丢失数据的原因 5)对地址和电话采用多个字段描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2和Address_Line3可以提供更大的灵活性。还有,电话号码和邮件地址最好拥有自己的数据表,其间具有自身的类型和标记类别。 6)使用角色实体定义属于某类别的列在需要对属于特定类别或者具有特定角色的事物做定义时,可以用角色实体来创建特定的时间关联关系,从而可以实现自我文档化。举例:用PERSON实体和PERSON_TYPE实体来描述人员。比方说,当JohnSmith,Engineer提升为JohnSmith,Director乃至最后爬到JohnSmith,CIO的高位,而所有你要做的不过是改变两个表PERSON和PERSON_TYPE之间关系的键值,同时增加一个日期/时间字段来知道变化是何时发生的。这样,你的PERSON_TYPE表就包含了所有PERSON的可能类型,比如Associate、Engineer、Director、CIO或者CEO等。还有个替代办法就是改变PERSON记录来反映新头衔的变化,不过这样一来在时间上无法跟踪个人所处位置的具体时间。 7)选择数字类型和文本类型尽量充足在SQL中使用smallint和tinyint类型要特别小心。比如,假如想看看月销售总额,总额字段类型是smallint,那么,如果总额超过了$32,767就不能进行计算操作了。而ID类型的文本字段,比如客户ID或定单号等等都应该设置得比一般想象更大。假设客户ID为10位数长。那你应该把数据库表字段的长度设为12或者13个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。 8)增加删除标记字段在表中包含一个“删除标记”字段,这样就可以把行标记为删除。在关系数据库里不要单独删除某一行;最好采用清除数据