设计数据库须要考虑到的问题

成功的管理系统=50% 的业务+(25%的数据库+25%的程序)

一、考察现有系统环境
    大多数数据库项目都不是从头开始创建的，一般机构内总会存在用来知足特定需求的现有系统。显然，现有系统并不完美，不然你就没必要再创建新系统了。可是对旧系统的研究可让你发现一些可能会忽略的细微问题。通常来讲，考察现有系统对你绝对有好处。

二、充分预计需求的升级趋势
    询问用户如何看待将来需求变化很是有用，这样作能够达到两个目的：首先，能够清楚地了解应用设计在哪一个地方应该更具灵活性以及如何避免性能瓶颈；其次，知道发生事先没有肯定的需求变动时用户将和你同样感到吃惊。

三、充分理解客户的需求
       看起来这应该是显而易见的事，但需求就是来自客户（这里要从内部和外部客户的角度考虑）。不要依赖用户写下来的需求，真正的需求在客户的脑壳里。你要让客户解释其需求，并且随着开发的继续，还要常常询问客户保证其需求仍然在开发的目的之中。
    一旦你认为你已经明确了业务内容，你最好同客户进行一次系统的交流。采用客户的术语而且向他们解释你所想到的和你所听到的。同时还应该用可能、将会和必须等词汇表达出系统的关系基数。这样你就可让你的客户纠正你本身的理解。
    了解业务能够在之后的开发阶段节约大量的时间，而其你会发现，一旦你明确了业务需求，你就能够本身作出许多决策了。

四、肯定数据对象的命名规范
    必定要定义数据库对象的命名规范，能够考虑用约定好的前缀或后缀：
对于视图来讲，能够采用vw_前缀；
对表来讲，表名能够加上前缀tbl_；
对表内的列[字段]来讲，数字类型能够用_N做为后缀，字符类型能够采用_C后缀等，Money类型能够采用_M后缀，日期类型能够采用_D做为后缀等等；
对于存储过程来讲，能够采用sp_前缀；
对于自定义函数，能够考虑采用udf_前缀；
此外，采用全大写字母，且如下划线分割单词，如：TBL_CUSTOMER_INFO

五、建立数据字典
    必定要花点时间建立数据字典，其中至少应该包含每一个字段的数据类型和在每一个表内的主外键。建立数据字典确实有点费时但对其余开发人员要了解整个设计倒是彻底必要的。越早建立越能有助于避免从此面临的可能混乱，从而可让任何了解数据库的人都明确如何从数据库中得到数据。
 
六、从输入输出下手
    在定义数据库表和字段需求（输入）时，首先应检查现有的或者已经设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段。举个简单的例子：假如客户须要一个报表按照邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。

七、报表技巧
    要了解用户一般是如何报告数据的：批处理仍是在线提交报表？时间间隔是天天、每周、每个月、每一个季度仍是每一年？若是须要的话还能够考虑建立总结表。系统生成的主键在报表中很难管理。用户在具备系统生成主键的表内用副键进行检索每每会返回许多重复数据。这样的检索性能比较低并且容易引发混乱。

八、考虑国际化问题
    在设计用到网络或者具备其余国际特性的数据库时，必定要记住大多数国家都有不一样的字段格式，好比邮政编码等，有些国家，好比新西兰就没有邮政编码一说。

九、记录的版本
    借鉴Oracle的设计模式，每一个表都设置如下6个字段：
    Create_Date
    Last_Modify_Date
    Creator
    Modifier
    Modify_Number
    Is_Deleted
在表中包含一个“删除标记”字段，这样就能够把行标记为删除。在关系数据库里不要单独删除某一行；最好采用清除数据程序并且要仔细维护索引总体性。
 
十、仔细选择数据类型
    在SQL中使用smallint和 tinyint类型要特别当心，好比，假如你想看看月销售总额，你的总额字段类型是 smallint，那么，若是总额超过了$32,767你就不能进行计算操做了。
    在命名字段并为其指定数据类型的时候必定要保证一致性。假如字段在某个表中叫作“agreement_number”，你就别在另外一个表里把名字改为“ref1”。假如数据类型在一个表里是整数，那在另外一个表里可就别变成字符型了。记住，你干完本身的活了，其余人还要用你的数据库呢。
 
十一、尽可能避免使用触发器
    触发器的功能一般能够用其余方式实现。在调试程序时触发器可能成为干扰。假如你确实须要采用触发器，你最好集中对它文档化。

十二、给文本字段留足余量
    ID类型的文本字段，好比客户ID或定单号等等都应该设置得比通常想象更大，由于时间不长你多半就会由于要添加额外的字符而难堪不已。比方说，假设你的客户 ID为10位数长。那你应该把数据库表字段的长度设为12或者13个字符长。这算浪费空间吗？是有一点，但也没你想象的那么多：一个字段加长3个字符在有1百万条记录，再加上一点索引的状况下才不过让整个数据库多占据3MB的空间。但这额外占据的空间却无需未来重构整个数据库就能够实现数据库规模的增加了。身份证的号码从15位变成18位就是最好和最惨痛的例子。

1三、用约束而非商务规则强制数据完整性
    若是你按照商务规则来处理需求，那么你应当检查商务层次/用户界面：若是商务规则之后发生变化，那么只须要进行更新便可。假如需求源于维护数据完整性的须要，那么在数据库层面上须要施加限制条件。若是你在数据层确实采用了约束，你要保证有办法把更新不能经过约束检查的缘由采用用户理解的语言通知用户界面。除非你的字段命名很冗长，不然字段名自己还不够。
    只要有可能，请采用数据库系统实现数据的完整性。这不但包括经过标准化实现的完整性并且还包括数据的功能性。在写数据的时候还能够增长触发器来保证数据的正确性。不要依赖于商务层保证数据完整性；它不能保证表之间（外键）的完整性因此不能强加于其余完整性规则之上。

1四、分布式数据系统
    对分布式系统而言，在你决定是否在各个站点复制全部数据仍是把数据保存在一个地方以前应该估计一下将来 5年或者 10年的数据量。当你把数据传送到其余站点的时候，最好在数据库字段中设置一些标记。在目的站点收到你的数据以后更新你的标记。为了进行这种数据传输，请写下你本身的批处理或者调度程序以特定时间间隔运行而不要让用户在天天的工做后传输数据。本地拷贝你的维护数据，好比计算常数和利息率等，设置版本号保证数据在每一个站点都彻底一致。

1五、强制指示完整性(参照完整性?)
    没有好办法能在有害数据进入数据库以后消除它，因此你应该在它进入数据库以前将其剔除。激活数据库系统的指示完整性特性。这样能够保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。

1六、关系
    若是两个实体之间存在多对一关系，并且还有可能转化为多对多关系，那么你最好一开始就设置成多对多关系。从现有的多对一关系转变为多对多关系比一开始就是多对多关系要可贵多。

1七、采用视图
    为了在你的数据库和你的应用程序代码之间提供另外一层抽象，你能够为你的应用程序创建专门的视图而没必要非要应用程序直接访问数据表。这样作还等于在处理数据库变动时给你提供了更多的自由。

1八、别忘了索引
    索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题均可以采用索引技术获得解决。做为一条规则，我一般对逻辑主键使用惟一的成组索引，对系统键（做为存储过程）采用惟一的非成组索引，对任何外键列[字段]采用非成组索引。不过，索引就象是盐，太多了菜就咸了。你得考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用做读写。
    大多数数据库都索引自动建立的主键字段，可是可别忘了索引外键，它们也是常用的键，好比运行查询显示主表和全部关联表的某条记录就用得上。还有，不要索引 memo/note字段，不要索引大型字段（有不少字符），这样做会让索引占用太多的存储空间。

1九、用存储过程让系统作重活
    解决了许多麻烦来产生一个具备高度完整性的数据库解决方案以后，我决定封装一些关联表的功能组，提供一整套常规的存储过程来访问各组以便加快速度和简化客户程序代码的开发。数据库不仅是一个存放数据的地方，它也是简化编码之地。
 
20、使用系统生成的主键    假如你老是在设计数据库的时候采用系统生成的键做为主键，那么你实际控制了数据库的索引完整性。这样，数据库和非人工机制就有效地控制了对存储数据中每一行的访问。采用系统生成键做为主键还有一个优势：当你拥有一致的键结构时，找到逻辑缺陷很容易。