数据库设计技巧奉送了

1. 设计数据库之前(需求分析阶段)
    1) 理解客户需求,询问用户如何看待未来需求变化。让客户解释其需求,而且随着开发的继续,还要经常询问客户保证其需求仍然在开发的目的之中。
    2) 了解企业业务可以在以后的开发阶段节约大量的时间。
    3) 重视输入输出。
    在定义数据库表和字段需求(输入)时,首先应检查现有的或者已经设计出的报表、查询和视图(输出)以决定为了支持这些输出哪些是必要的表和字段。
    举例:假如客户需要一个报表按照邮政编码排序、分段和求和,你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。
    4) 创建数据字典和ER 图表
    ER 图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用,而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL 表达式的文档化来说这是完全必要的。
    5) 定义标准的对象命名规范
    数据库各种对象的命名必须规范。
    2. 表和字段的设计(数据库逻辑设计)
    表设计原则
    1) 标准化和规范化
    数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式,但Third Normal Form(3NF)通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说,遵守3NF 标准的数据库的表设计原则是:“One Fact in One Place”即某个表只包括其本身基本的属性,当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点:有一组表专门存放通过键连接起来的关联数据。
    举例:某个存放客户及其有关定单的3NF 数据库就可能有两个表:Customer 和Order。Order 表不包含定单关联客户的任何信息,但表内
会存放一个键值,该键指向Customer 表里包含该客户信息的那一行。
    事实上,为了效率的缘故,对表不进行标准化有时也是必要的。
    2) 数据驱动
    采用数据驱动而非硬编码的方式,许多策略变更和维护都会方便得多,大大增强系统的灵活性和扩展性。
    举例,假如用户界面要访问外部数据源(文件、XML 文档、其他数据库等),不妨把相应的连接和路径信息存储在用户界面支持表里。还有,如果用户界面执行工作流之类的任务(发送邮件、打印信笺、修改记录状态等),那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上,如果过程是数据驱动的,你就可以把相当大的责任推给用户,由用户来维护自己的工作流过程。
    3) 考虑各种变化
    在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。
    举例,姓氏就是如此(注意是西方人的姓氏,比如女性结婚后从夫姓等)。所以,在建立系统存储客户信息时,在单独的一个数据表里存储姓氏字段,而且还附加起始日和终止日等字段,这样就可以跟踪这一数据条目的变化。
    字段设计原则
    4) 每个表中都应该添加的3 个有用的字段
dRecordCreationDate,在VB    • 下默认是Now(),而在SQL Server 下默认为GETDATE()
sRecordCreator,在SQL Server 下默认为NOT    • NULL DEFAULT USER
nRecordVersion,记录的版本标记;有助于准确说明记录中出现null    • 数据或者丢失数据的原因
    5) 对地址和电话采用多个字段
    描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的灵活性。还有,电话号码和邮件地址最好拥有自己的数据表,其间具有自身的类型和标记类别。
    6) 使用角色实体定义属于某类别的列
    在需要对属于特定类别或者具有特定角色的事物做定义时,可以用角色实体来创建特定的时间关联关系,从而可以实现自我文档化。
    举例:用PERSON 实体和PERSON_TYPE 实体来描述人员。比方说,当John Smith, Engineer 提升为John Smith, Director 乃至最后爬到John Smith, 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) 增加删除标记字段
    在表中包含一个“删除标记”字段,这样就可以把行标记为删除。在关系数据库里不要单独删除某一行;最好采用清除数据程序而且要仔细维护索引整体性。 
    3. 选择键和索引(数据库逻辑设计)
    键选择原则:
    1) 键设计4 原则
为关联字段创建外键。    •
    所有的键都必须唯一。•
避免使用复合键。    •
外键总是关联唯一的键字段。    •
    2) 使用系统生成的主键
    设计数据库的时候采用系统生成的键作为主键,那么实际控制了数据库的索引完整性。这样,数据库和非人工机制就有效地控制了对存储数据中每一行的访问。采用系统生成键作为主键还有一个优点:当拥有一致的键结构时,找到逻辑缺陷很容易。
    3) 不要用用户的键(不让主键具有可更新性)
    在确定采用什么字段作为表的键的时候,可一定要小心用户将要编辑的字段。通常的情况下不要选择用户可编辑的字段作为键。
    4) 可选键有时可做主键
    把可选键进一步用做主键,可以拥有建立强大索引的能力。
    索引使用原则:
    索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到解决。
    1) 逻辑主键使用唯一的成组索引,对系统键(作为存储过程)采用唯一的非成组索引,对任何外键列采用非成组索引。考虑数据库的空间有多大,表如何进行访问,还有这些访问是否主要用作读写。
    2) 大多数数据库都索引自动创建的主键字段,但是可别忘了索引外键,它们也是经常使用的键,比如运行查询显示主表和所有关联表的某条记录就用得上。
    3) 不要索引memo/note 字段,不要索引大型字段(有很多字符),这样作会让索引占用太多的存储空间。
    4) 不要索引常用的小型表
    不要为小型数据表设置任何键,假如它们经常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。
    4. 数据完整性设计(数据库逻辑设计)
    1) 完整性实现机制:
    实体完整性:主键
    参照完整性:
    父表中删除数据:级联删除;受限删除;置空值
    父表中插入数据:受限插入;递归插入
    父表中更新数据:级联更新;受限更新;置空值
    DBMS对参照完整性可以有两种方法实现:外键实现机制(约束规则)和触发器实现机制
    用户定义完整性:
    NOT NULL;CHECK;触发器
    2) 用约束而非商务规则强制数据完整性
    采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于商务层保证数据完整性;它不能保证表之间(外键)的完整性所以不能强加于其他完整性规则之上。
    3) 强制指示完整性
    在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。
    4) 使用查找控制数据完整性
    控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找:国家代码、状态代码等。
    5) 采用视图
    为了在数据库和应用程序代码之间提供另一层抽象,可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。
    5. 其他设计技巧
    1) 避免使用触发器
    触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器,你最好集中对它文档化。
    2) 使用常用英语(或者其他任何语言)而不要使用编码
    在创建下拉菜单、列表、报表时最好按照英语名排序。假如需要编码,可以在编码旁附上用户知道的英语。
    3) 保存常用信息
    让一个表专门存放一般数据库信息非常有用。在这个表里存放数据库当前版本、最近检查/修复(对Access)、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库,当客户抱怨他们的数据库没有达到希望的要求而与你联系时,这样做对非客户机/服务器环境特别有用。
    4) 包含版本机制
    在数据库中引入版本控制机制来确定使用中的数据库的版本。时间一长,用户的需求总是会改变的。最终可能会要求修改数据库结构。把版本信息直接存放到数据库中更为方便。 
    5) 编制文档
    对所有的快捷方式、命名规范、限制和函数都要编制文档。
    采用给表、列、触发器等加注释的数据库工具。对开发、支持和跟踪修改非常有用。
    对数据库文档化,或者在数据库自身的内部或者单独建立文档。这样,当过了一年多时间后再回过头来做第2 个版本,犯错的机会将大大减少。
    6) 测试、测试、反复测试
    建立或者修订数据库之后,必须用用户新输入的数据测试数据字段。最重要的是,让用户进行测试并且同用户一道保证选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。
    7) 检查设计
    在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说,针对每一种最终表达数据的原型应用,保证你检查了数据模型并且查看如何取出数据。
    三、数据库命名规范
    1. 实体(表)的命名
    1) 表以名词或名词短语命名,确定表名是采用复数还是单数形式,此外给表的别名定义简单规则(比方说,如果表名是一个单词,别名就取单词的前4 个字母;如果表名是两个单词,就各取两个单词的前两个字母组成4 个字母长的别名;如果表的名字由3 个单词组成,从头两个单词中各取一个然后从最后一个单词中再取出两个字母,结果还是组成4 字母长的别名,其余依次类推)
    对工作用表来说,表名可以加上前缀WORK_ 后面附上采用该表的应用程序的名字。在命名过程当中,根据语义拼凑缩写即可。注意,由于ORCLE会将字段名称统一成大写或者小写中的一种,所以要求加上下划线。
    举例:
    定义的缩写 Sales: Sal 销售;
    Order: Ord 订单;
    Detail: Dtl 明细;
    则销售订单明细表命名为:Sal_Ord_Dtl;
    2) 如果表或者是字段的名称仅有一个单词,那么建议不使用缩写,而是用完整的单词。
    举例:
    定义的缩写 Material Ma 物品;
    物品表名为:Material, 而不是 Ma.
    但是字段物品编码则是:Ma_ID;而不是Material_ID
    3) 所有的存储值列表的表前面加上前缀Z
    目的是将这些值列表类排序在数据库最后。
    4) 所有的冗余类的命名(主要是累计表)前面加上前缀X
    冗余类是为了提高数据库效率,非规范化数据库的时候加入的字段或者表
    5) 关联类通过用下划线连接两个基本类之后,再加前缀R的方式命名,后面按照字母顺序罗列两个表名或者表名的缩写。
    关联表用于保存多对多关系。
    如果被关联的表名大于10个字母,必须将原来的表名的进行缩写。如果没有其他原因,建议都使用缩写。
    举例:表Object与自身存在多对多的关系,则保存多对多关系的表命名为:R_Object;
    表 Depart和Employee;存在多对多的关系;则关联表命名为R_Dept_Emp
    2. 属性(列)的命名
    1) 采用有意义的列名,表内的列要针对键采用一整套设计规则。每一个表都将有一个自动ID作为主健,逻辑上的主健作为第一组候选主健来定义,如果是数据库自动生成的编码,统一命名为:ID;如果是自定义的逻辑上的编码则用缩写加“ID”的方法命名。如果键是数字类型,你可以用_NO 作为后缀;如果是字符类型则可以采用_CODE 后缀。对列名应该采用标准的前缀和后缀。
    举例:销售订单的编号字段命名:Sal_Ord_ID;如果还存在一个数据库生成的自动编号,则命名为:ID。
    2) 所有的属性加上有关类型的后缀,注意,如果还需要其它的后缀,都放在类型后缀之前。
    注: 数据类型是文本的字段,类型后缀TX可以不写。有些类型比较明显的字段,可以不写类型后缀。
    3) 采用前缀命名
    给每个表的列名都采用统一的前缀,那么在编写SQL表达式的时候会得到大大的简化。这样做也确实有缺点,比如破坏了自动表连接工具的作用,后者把公共列名同某些数据库联系起来。
    3. 视图的命名
    1) 视图以V作为前缀,其他命名规则和表的命名类似;
    2) 命名应尽量体现各视图的功能。
    4. 触发器的命名
    触发器以TR作为前缀,触发器名为相应的表名加上后缀,Insert触发器加"_I",Delete触发器加"_D",Update触发器加"_U",如:    TR_Customer_I,TR_Customer_D,TR_Customer_U。
    5. 存储过程名
    存储过程应以"UP_"开头,和系统的存储过程区分,后续部分主要以动宾形式构成,并用下划线分割各个组成部分。如增加代理商的帐户的存储过程为"UP_Ins_Agent_Account"。
    6. 变量名
    变量名采用小写,若属于词组形式,用下划线分隔每个单词,如@my_err_no。
    7. 命名中其他注意事项
    1)  以上命名都不得超过30个字符的系统限制。变量名的长度限制为29(不包括标识字符@)。
    2)  数据对象、变量的命名都采用英文字符,禁止使用中文命名。绝对不要在对象名的字符之间留空格。
    3) 小心保留词,要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突
    5) 保持字段名和类型的一致性,在命名字段并为其指定数据类型的时候一定要保证一致性。假如数据类型在一个表里是整数,那在另一个表里可就别变成字符型了

(0)

相关推荐

  • 数据库设计技巧奉送了

    1. 设计数据库之前(需求分析阶段)     1) 理解客户需求,询问用户如何看待未来需求变化.让客户解释其需求,而且随着开发的继续,还要经常询问客户保证其需求仍然在开发的目的之中.     2) 了解企业业务可以在以后的开发阶段节约大量的时间.     3) 重视输入输出.     在定义数据库表和字段需求(输入)时,首先应检查现有的或者已经设计出的报表.查询和视图(输出)以决定为了支持这些输出哪些是必要的表和字段.     举例:假如客户需要一个报表按照邮政编码排序.分段和求和,你要保证其中

  • 数据库设计技巧[转]

    1. 原始单据与实体之间的关系 可以是一对一.一对多.多对多的关系.在一般情况下,它们是一对一的关系:即一张原始单据对应且只对应一个实体.在特殊情况下,它们可能是一对多或多对一的关系,即一张原始单证对应多个实体,或多张原始单证对应一个实体.这里的实体可以理解为基本表.明确这种对应关系后,对我们设计录入界面大有好处. [例1]:一份员工履历资料,在人力资源信息系统中,就对应三个基本表:员工基本情况表.社会关系表.工作简历表.这就是"一张原始单证对应多个实体"的典型例子. 2. 主键与外键

  • 数据库设计的折衷方法

    作项目分析,数据库设计是一个很重要也很难的问题, 完全按照范式有可能不符合用户需求,不利于编程, 看来是具体问题具体分析,数据库设计是范式和需求的折中. 在上学时,没觉得数据类型有多重要,现在发觉了解数据类型 的具体内容也是很重要的,可以知道不同数据库之间的兼容问题 该怎么处理. 数据库设计技巧: 第2 部分- 设计表和字段 1. 检查各种变化 我在设计数据库的时候会考虑到哪些数据字段将来可能会发生变更.比方说,姓氏就是如此(注 意是西方人的姓氏,比如女性结婚后从夫姓等).所以,在建立系统存储客

  • 数据库正规化和设计技巧

    在动态网站的设计中,数据库设计的重要性不言而喻.如果设计不当,查询起来就非常吃力,程序的性能也会受到影响.无论你使用的是mySQL或者Oracle数据库,通过进行正规化的表格设计,可以令你的PHP代码更具可读性,更容易扩展,从而也会提升应用的性能.  简单说来,正规化就是在表格设计时,消除冗余性和不协调的从属关系.在本文中,我将通过五个渐进的过程来告诉你在设计中应该了解的正规化技巧.从而建立一个可行而且效率高的数据库.本文也会详细分析一下可以利用的关系类型. 这里假定我们要建立一个用户信息的表格

  • 数据库设计规范化的五个要求 推荐收藏

    若符合这两个条件,则可以说明这个数据库的规范化水平还是比较高的.当然这是两个泛泛而谈的指标.为了达到数据库设计规范化的要求,一般来说,需要符合以下五个要求. 要求一:表中应该避免可为空的列. 虽然表中允许空列,但是,空字段是一种比较特殊的数据类型.数据库在处理的时候,需要进行特殊的处理.如此的话,就会增加数据库处理记录的复杂性.当表中有比较多的空字段时,在同等条件下,数据库处理的性能会降低许多. 所以,虽然在数据库表设计的时候,允许表中具有空字段,但是,我们应该尽量避免.若确实需要的话,我们可以

  • 数据库设计经验谈

    一个成功的管理系统,是由:[50% 的业务 + 50% 的软件] 所组成,而 50% 的成功软件又有 [25% 的数据库 + 25% 的程序] 所组成,数据库设计的好坏是一个关键.如果把企业的数据比做生命所必需的血液,那么数据库的设计就是应用中最重要的一部分.有关数据库设计的材料汗牛充栋,大学学位课程里也有专门的讲述.不过,就如我们反复强调的那样,再好的老师也比不过经验的教诲.所以我归纳历年来所走的弯路及体会,并在网上找了些对数据库设计颇有造诣的专业人士给大家传授一些设计数据库的技巧和经验.精选

  • 简单了解MySQL数据库优化技巧

    一个成熟的数据库架构并不是一开始设计就具备高可用.高伸缩等特性的,它是随着用户量的增加,基础架构才逐渐完善.这篇文章主要谈谈MySQL数据库在发展周期中所面临的问题及优化方案,暂且抛开前端应用不说,大致分为以下五个阶段: 阶段一:数据库表设计 项目立项后,开发部门根据产品部门需求开发项目. 开发工程师在开发项目初期会对表结构设计.对于数据库来说,表结构设计很重要,如果设计不当,会直接影响到用户访问网站速度,用户体验不好!这种情况具体影响因素有很多,例如慢查询(低效的查询语句).没有适当建立索引.

  • MySQL数据库设计之利用Python操作Schema方法详解

    弓在箭要射出之前,低声对箭说道,"你的自由是我的".Schema如箭,弓似Python,选择Python,是Schema最大的自由.而自由应是一个能使自己变得更好的机会. Schema是什么? 不管我们做什么应用,只要和用户输入打交道,就有一个原则--永远不要相信用户的输入数据.意味着我们要对用户输入进行严格的验证,web开发时一般输入数据都以JSON形式发送到后端API,API要对输入数据做验证.一般我都是加很多判断,各种if,导致代码很丑陋,能不能有一种方式比较优雅的验证用户数据呢

  • MySQL 数据库设计复习笔记及项目实战

    作者:杨鑫奇 最近手头上有3个项目开动,其他2个都是从底层开始的,一个已经开始了一段时间的了,在小城市小团队开发的条件下,都没有专门的DBA来做数据库的设计和维护,往往都是开发人员顶上,可是看了很多的数据库的设计,感觉很多设计都不是很完美,包括DZ的Ucenter和UcenterHome的数据库,所以这段时间话了近5个小时的时间好好的整理了下数据库方面的基本内容,配合现有的框架来实现快捷的数据库设计,来满足目前项目的需求 参考的数据库文档主要有:目前国内的常见的PHP系统的数据库 DZ6.0的数

  • 复杂系统中的用户权限数据库设计解决方案

    B/S系统中的权限比C/S中的更显的重要,C/S系统因为具有特殊的客户端,所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现,而B/S中,浏览器是每一台计算机都已具备的,如果不建立一个完整的权限检测,那么一个"非法用户"很可能就能通过浏览器轻易访问到B/S系统中的所有功能.因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测,让经过授权的用户可以正常合法的使用已授权功能,而对那些未经授权的"非法用户"将会将他们彻底的"拒之门外&

随机推荐