设计数据库时需要考虑的问题
成功的管理系统=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%的数据库性能问题都可以采用索引技术得到解决。作为一条规则，我通常对逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非成组索引，对任何外键列[字段]采用非成组索引。不过，索引就象是盐，太多了菜就咸了。你得考虑数据库的空间有多大，表如何