成功的管理系统=50% 的业务+(25%的数据库+25%的程序)
1、考察现有系统环境
大多数数据库项目都不是从头开始建立的,通常机构内总会存在用来满足特定需求的现有系统。显然,现有系统并不完美,否则你就不必再建立新系统了。但是对旧系统的研究可以让你发现一些可能会忽略的细微问题。一般来说,考察现有系统对你绝对有好处。
2、充分预计需求的升级趋势
询问用户如何看待未来需求变化非常有用,这样做可以达到两个目的:首先,可以清楚地了解应用设计在哪个地方应该更具灵活性以及如何避免性能瓶颈;其次,知道发生事先没有确定的需求变更时用户将和你一样感到吃惊。
3、充分理解客户的需求
看起来这应该是显而易见的事,但需求就是来自客户(这里要从内部和外部客户的角度考虑)。不要依赖用户写下来的需求,真正的需求在客户的脑袋里。你要让客户解释其需求,而且随着开发的继续,还要经常询问客户保证其需求仍然在开发的目的之中。
一旦你认为你已经明确了业务内容,你最好同客户进行一次系统的交流。采用客户的术语并且向他们解释你所想到的和你所听到的。同时还应该用可能、将会和必须等词汇表达出系统的关系基数。这样你就可以让你的客户纠正你自己的理解。
了解业务可以在以后的开发阶段节约大量的时间,而其你会发现,一旦你明确了业务需求,你就可以自己做出许多决策了。
4、确定数据对象的命名规范
一定要定义数据库对象的命名规范,可以考虑用约定好的前缀或后缀:
对于视图来说,可以采用vw_前缀;
对表来说,表名可以加上前缀tbl_;
对表内的列[字段]来说,数字类型可以用_N作为后缀,字符类型可以采用_C后缀等,Money类型可以采用_M后缀,日期类型可以采用_D作为后缀等等;
对于存储过程来说,可以采用sp_前缀;
对于自定义函数,可以考虑采用udf_前缀;
此外,采用全大写字母,且以下划线分割单词,如:TBL_CUSTOMER_INFO
5、创建数据字典
一定要花点时间创建数据字典,其中至少应该包含每个字段的数据类型和在每个表内的主外键。创建数据字典确实有点费时但对其他开发人员要了解整个设计却是完全必要的。越早创建越能有助于避免今后面临的可能混乱,从而可以让任何了解数据库的人都明确如何从数据库中获得数据。
6、从输入输出下手
在定义数据库表和字段需求(输入)时,首先应检查现有的或者已经设计出的报表、查询和视图(输出)以决定为了支持这些输出哪些是必要的表和字段。举个简单的例子:假如客户需要一个报表按照邮政编码排序、分段和求和,你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。
7、报表技巧
要了解用户通常是如何报告数据的:批处理还是在线提交报表?时间间隔是每天、每周、每月、每个季度还是每年?如果需要的话还可以考虑创建总结表。系统生成的主键在报表中很难管理。用户在具有系统生成主键的表内用副键进行检索往往会返回许多重复数据。这样的检索性能比较低而且容易引起混乱。
8、考虑国际化问题
在设计用到网络或者具有其他国际特性的数据库时,一定要记住大多数国家都有不同的字段格式,比如邮政编码等,有些国家,比如新西兰就没有邮政编码一说。
9、记录的版本
借鉴Oracle的设计模式,每个表都设置以下6个字段:
Create_Date
Last_Modify_Date
Creator
Modifier
Modify_Number
Is_Deleted
在表中包含一个“删除标记”字段,这样就可以把行标记为删除。在关系数据库里不要单独删除某一行;最好采用清除数据程序而且要仔细维护索引整体性。
10、仔细选择数据类型
在SQL中使用smallint和 tinyint类型要特别小心,比如,假如你想看看月销售总额,你的总额字段类型是 smallint,那么,如果总额超过了$32,767你就不能进行计算操作了。
在命名字段并为其指定数据类型的时候一定要保证一致性。假如字段在某个表中叫做“agreement_number”,你就别在另一个表里把名字改成“ref1”。假如数据类型在一个表里是整数,那在另一个表里可就别变成字符型了。记住,你干完自己的活了,其他人还要用你的数据库呢。
11、尽量避免使用触发器
触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器,你最好集中对它文档化。
12、给文本字段留足余量
ID类型的文本字段,比如客户ID或定单号等等都应该设置得比一般想象更大,因为时间不长你多半就会因为要添加额外的字符而难堪不已。比方说,假设你的客户 ID为10位数长。那你应该把数据库表字段的长度设为12或者13个字符长。这算浪费空间吗?是有一点,但也没你想象的那么多:一个字段加长3个字符在有1百万条记录,再加上一点索引的情况下才不过让整个数据库多占据3MB的空间。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。身份证的号码从15位变成18位就是最好和最惨痛的例子。
13、用约束而非商务规则强制数据完整性
如果你按照商务规则来处理需求,那么你应当检查商务层次/用户界面:如果商务规则以后发生变化,那么只需要进行更新即可。假如需求源于维护数据完整性的需要,那么在数据库层面上需要施加限制条件。如果你在数据层确实采用了约束,你要保证有办法把更新不能通过约束检查的原因采用用户理解的语言通知用户界面。除非你的字段命名很冗长,否则字段名本身还不够。
只要有可能,请采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于商务层保证数据完整性;它不能保证表之间(外键)的完整性所以不能强加于其他完整性规则之上。
14、分布式数据系统
对分布式系统而言,在你决定是否在各个站点复制所有数据还是把数据保存在一个地方之前应该估计一下未来 5年或者 10年的数据量。当你把数据传送到其他站点的时候,最好在数据库字段中设置一些标记。在目的站点收到你的数据之后更新你的标记。为了进行这种数据传输,请写下你自己的批处理或者调度程序以特定时间间隔运行而不要让用户在每天的工作后传输数据。本地拷贝你的维护数据,比如计算常数和利息率等,设置版本号保证数据在每个站点都完全一致。
15、强制指示完整性(参照完整性?)
没有好办法能在有害数据进入数据库之后消除它,所以你应该在它进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。
16、关系
如果两个实体之间存在多对一关系,而且还有可能转化为多对多关系,那么你最好一开始就设置成多对多关系。从现有的多对一关系转变为多对多关系比一开始就是多对多关系要难得多。
17、采用视图
为了在你的数据库和你的应用程序代码之间提供另一层抽象,你可以为你的应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。
18、别忘了索引
索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到解决。作为一条规则,我通常对逻辑主键使用唯一的成组索引,对系统键(作为存储过程)采用唯一的非成组索引,对任何外键列[字段]采用非成组索引。不过,索引就象是盐,太多了菜就咸了。你得考虑数据库的空间有多大,表如何进行访问,还有这些访问是否主要用作读写。
大多数数据库都索引自动创建的主键字段,但是可别忘了索引外键,它们也是经常使用的键,比如运行查询显示主表和所有关联表的某条记录就用得上。还有,不要索引 memo/note字段,不要索引大型字段(有很多字符),这样作会让索引占用太多的存储空间。
19、用存储过程让系统做重活
解决了许多麻烦来产生一个具有高度完整性的数据库解决方案之后,我决定封装一些关联表的功能组,提供一整套常规的存储过程来访问各组以便加快速度和简化客户程序代码的开发。数据库不只是一个存放数据的地方,它也是简化编码之地。
20、使用系统生成的主键
假如你总是在设计数据库的时候采用系统生成的键作为主键,那么你实际控制了数据库的索引完整性。这样,数据库和非人工机制就有效地控制了对存储数据中每一行的访问。采用系统生成键作为主键还有一个优点:当你拥有一致的键结构时,找到逻辑缺陷很容易。
分享到:
相关推荐
在设计数据库之前,首先要进行需求分析,明确要解决的问题,识别关键实体和它们之间的关系。这通常涉及到业务流程的了解、用户需求的访谈以及数据流图的绘制。 四、概念设计 概念设计阶段,将需求转化为实体-关系...
2. 在数据库设计中,需要考虑到用户与学生信息之间的关系,设计全局ER图,以便更好地存储和管理学生信息。 3. 学生信息实体可以转化为sinfo表,包括sid、sname、scounty、sintime、sbirtyday、ssex、sremarks等列名...
- 数据量的增长是不可避免的,因此在设计数据库时应该考虑到这一点。例如,Y2K问题之前,很多系统都因为没有考虑到未来数据的增长而导致了一系列的问题。为了避免这类问题,设计者应当预留足够的空间来应对未来的...
数据库设计是信息系统...以上内容是对“数据库设计中值得注意的问题”的概述,具体的设计过程需要结合实际情况和业务需求,灵活运用这些原则。通过深入理解和实践,我们可以创建出高效、稳定、易于维护的数据库系统。
6. **性能优化**:考虑到排课系统可能面临的大量并发请求,数据库设计还需要考虑性能优化。这可能包括合理的数据分区、读写分离、缓存策略以及选择适合的数据库引擎(如InnoDB支持事务处理)。 7. **安全性与备份**...
在设计数据库时,我们需要考虑到实体、属性和关系等因素。例如,在客户订货系统中,客户信息、产品信息、订单信息等实体之间存在着复杂的关系,我们需要通过建立信息模型来描述这些关系,并设计出合适的数据库结构。...
对于系统可能遇到的各类威胁,设计者应该在设计阶段就考虑到相应的防御措施,确保系统在运行时的安全性。 综上所述,数据库课程设计是一个理论与实践相结合的过程,旨在提升学生将数据库理论应用于实际问题的能力,...
数据库设计还需要考虑数据的一致性、完整性和安全性。例如,通过设置合适的约束条件确保数据的完整性,如主键约束确保每条记录的唯一性,外键约束保证引用完整性。此外,还需要考虑性能优化,比如通过合理设计索引来...
数据库设计需要考虑数据的一致性、完整性和安全性,同时也要考虑查询性能和扩展性。常用的工具有ERWin、Visio等,设计完成后通常会生成DDL脚本用于创建数据库。 这些设计规范和模板提供了标准的格式和内容指南,...
数据库设计规范是指在设计数据库时需要遵循的规则和标准,以确保数据库的设计是合理、科学和高效的。本文档将详细介绍数据库设计规范的各个方面,包括设计原则、命名规范、设计文件内容等。 设计原则 数据库设计...
这部分列举了设计数据库时参考的相关文献、标准或已有的数据库设计方案,为设计决策提供理论依据和技术支持。 2. 数据库环境说明 这部分描述了数据库运行的硬件、软件环境,包括数据库管理系统(DBMS)的选择、操作...
设计时还需考虑数据的时效性,例如,未完成的交易可能需要进入“等待充值”状态,而超时未完成的交易则可能需要被“撤销”。 数据库设计文档还提到了一些其他的表,如“退款交易流水表”,这些表之间通过不同的字段...
数据库设计的准则是指在设计数据库时需要遵循的一些基本原则,这些原则旨在确保数据库的正确性、完整性和可扩展性。以下是数据库设计的准则: 1.第三范式:数据库设计的目标是遵循第三范式,以确保数据库的正确性和...
电商系统数据库设计 电商系统的数据库设计是电商系统的核心...电商系统的数据库设计是电商系统的核心组件之一,需要考虑到系统的业务需求、技术架构和数据库设计原则等多方面因素,以便于提高系统的性能和可扩展性。
在实现多级目录数据库设计时,还需要考虑以下关键点: 1. **事务管理**:确保数据一致性,特别是在插入、删除或移动目录时,需要处理好并发和回滚情况。 2. **索引优化**:为提高查询性能,可能需要在父目录ID、...
数据库设计规范是指在设计数据库时,遵守的一些规则和标准,以确保数据库的结构合理、数据一致、易于维护和扩展。本文档将总结数据库设计规范的主要内容,包括数据库编码规范、字段设计规定、试图设计规则、索引设计...
通过对需求可追踪性的说明,开发者和维护者能够清晰地理解数据库设计背后的逻辑,并在问题发生时进行准确的定位和解决。 最后,DBDD中的注解部分对设计中可能存在的特殊考虑和限制进行说明。这些内容可能包括技术...
在 OA 协同办公系统数据库设计中,需要考虑到多方面的因素,包括系统的功能需求、数据的存储和管理、数据的安全性、系统的性能和可扩展性等。为了满足这些需求,需要对数据库进行详细的设计和规划,包括数据库的物理...