一、 数据库设计的一些总体规则
1、 弄清楚要开发的应用程序是事务处理型（OLTP）还是分析型（OLAP）,
如果用户更关注数据的增删改，也就是事务处理，那就设计一个规范化的表。
否则如果最终用户更关注数据分析、报表、趋势预测等等功能，也就是事务分析，那
就设计一个扁平的、不规范化的数据库结构。
2、 把重复、不统一的数据当成你最大的敌人来对待，重复数据可能会带来混乱而不仅仅是它们占用了多
少磁盘空间。解决方法之一是将这些数据完整地移到另外一个主表，然后通过外键引用过来。
3、 如果性能是关键，不要固执地去避免冗余,要把 “避免冗余” 当作是一条绝对的规则去遵循。
如果对性能有迫切的需求，考虑一下打破常规。常规情况下你需要做多个表的连接操作，
而在非常规的情况下这样的多表连接是会大大地降低性能的。
4、 将那些具有“名值表”特点的表统一起来设计,比如Currency（货币型）和 Country（国家）这两张表
都只有键和值。对于这种表，创建一个主要的表，通过一个 Type（类型）字段来区分不同的数据将会
更有意义。
5、 无限分级结构的数据，引用自己的主键作为外键来表达这种层级关系，从而达成目的。
6、选择恰当的数据类型，避免数据库的过度膨胀。如果你很清楚某列的数值范围在0-100,000之间，
那么就不必使用BIGINT数据类型，因为INT类型就已经足够了。
7、遵循ISO标准，保证异构数据库系统之间的互通性。大型企业的IT基础架构非常复杂，可能需要不同
数据库系统之间的数据交换。因此要尽可能地遵循ISO标准，以保证异构数据库系统之间的互通性。
8、以恰当的机制实现序列化。一些数据库设计者喜欢在数据库设计中引入GUID，但引入GUID并不是一个
好的选择，这是因为GUID默认并非序列化的，使用GUID列作为主键和/或索引甚至会造成性能问题。
9、创建索引时要将外键考虑在内。
10、不要忽略与业务需求相关的候选键，数据库设计者不应只将注意力放在代理键上，而忘却业务需求。
显然，这对数据质量非常不利。如果你没有在与业务相关的候选键上建立任何约束或索引，可能会出现
重复值。
二、数据库设计技巧
1、考察现有环境，在设计一个新数据库时，你不但应该仔细研究业务需求而且还要考察现有的系统。
2、定义标准的对象命名规范，对数据库表来说，从项目一开始就要定义数据库对象的命名规范。
3、检查各种变化，设计数据库的时候会考虑到哪些数据字段将来可能会发生变更。
4、采用有意义的字段名。
5、采用前缀命名。
6、标准化不能过头， 3NF通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。
简单来说，3NF 规定：
* 表内的每一个值都只能被表达一次。
* 表内的每一行都应该被唯一的标识（有唯一键）。
* 表内不应该存储依赖于其他键的非键信息。
7、数据重复需要采用分立的数据表，如果发现自己在重复输入数据，需创建新表和新的关系。
8、每个表中都应该添加的 3 个有用的字段
* dRecordCreationDate，记录的创建日期
* sRecordCreator，记录的创建人
* nRecordVersion，记录的版本标记；
9、对地址和电话采用多个字段，最好拥有自己的数据表，其间具有自身的类型和标记类别。便于提供
更大的 灵活性。
10. 使用多个名称字段，建议应该把姓氏和名字当作两个字段来处理，然后在查询的时候再把他们组合起来。
11、提防大小写混用的对象名和特殊字符，采用全部大写而且包含下划符的名字具有更好的可
读性（CUSTOMER_DATA），绝对不要在对象名的字符之间留空格。
12、小心保留词，要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突。
13、保持字段名和类型的一致性，同一字段在不同的数据表中应保持字段名称和类型的一致性。
14、仔细选择数字类型，确保数字类型的精度及大小能满足系统业务数据的需要。
15、避免使用触发器，触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。
假如确实需要采用触发器，最好集中对它文档化。
16、给文本字段留足余量，ID 类型的文本字段，比如客户 ID 或定单号等等都应该设置得比一般想象更大，
因为时间不长你多半就会因为要添加额外的字符而难堪不已。
17、使用系统生成的主键，假如你总是在设计数据库的时候采用系统生成的键作为主键，
那么你实际控制了数据库的索引完整性。
18、别忘了索引，索引是从数据库中获取数据的最高效方式之一。95% 的数据库性能问题都可以
采用索引技术得到解决。通常对逻辑主键使用唯一的成组索引，但别忘了索引外键，它们也是经常使用
的 键，比如运行查询显示主表和所有关联表的某条记录就用得上。另外，不要索引 memo/note 字段，
不要索引大型字段（有很多字符），这样做会让索引占用太多的存储空间。
19、不要索引常用的小型表，不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样
作 了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。
20、不要把社会保障号码（SSN）或身份证号码（ID）选作键，永远不要使用手工输入的键作为主键，
因为一旦你输入错误，你唯一能做的就是删除整个记录然后从头开始。
21、用约束而非商务规则强制数据完整性，只要有可能，请采用数据库系统实现数据的完整性。
22、如果两个实体之间存在多对一关系，而且还有可能转化为多对多关系，那么你最好一开始就设置成多
对 多关系。从现有的多对一关系转变为多对多关系比一开始就是多对多关系要难得多。
23、采用视图，为了在你的数据库和你的应用程序代码之间提供另一层抽象，你可以为你的应用程序建立专 门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。
24、用存储过程让系统做重活，封装一些关联表的功能组，提供一整套常规的存储过程来访问各组以便
加快 速度和简化客户程序代码的开发。数据库不只是一个存放数据的地方，它也是简化编码之地。
25、使用常用英语（或者其他任何语言）而不要使用编码，用户通常都用英语进行思考而不是编码。
26、不要把lob类型字段放到业务表里，最好建立单独的表存储lob信息，这样有利于系统的性能和数据库的维护。
三、数据库对象命名
1、推荐用英文单词给对象命名，因为英文单词语意比较精确，可读性比中文拼音好，并用下划线分隔多个单 词。
2、避免使用关键字，用关键字命名对象会造成冲突。
3、对象命名采用单数，考虑到英文名词的复数变化比较复杂, 全用复数会加大设计者的负担，并且容易
出错，从简化工作考虑，对象命名统一用单数即可。
4、字段命名采用全称，除非是众所周知的简称，一般情况下最好用更明确的全称，不要让别人猜测命名
的含 义，因为可读性对系统的可维护性影响很大。
5、布尔型字段在命名上增加 is_、has_、was_等前缀来增强可读性，例如enable用is_enable；
6、主键字段命名推荐用：表名 + "_id" , 这样能够保证主键命名的唯一性和可读性，如：
user表的主键用user_id；
7、外键字段命名最好与主表主键名称一致。这样做可读性好, 而且建模工具能够根据主键、
外键名称相同很方便的建立外键关联。
四、主键的设计
1、主键的必要性，主键是我们唯一标识一条记录的信息，在删除、修改记录时大都是通过主键来操作，
没有了主键，这些操作会很困难。
2、主键业务无关性，很多业务编号虽然具有唯一性，但不建议用来做主键，随着业务的变化，会带来一
系列 的麻烦。
3、主键的生成方案
（1）数值的自增，这种方案利用数据库自身的特性，如：Oracle里的序列来保证唯一性，
依赖于具体的数据库产品，有移植的问题。该方案最大的隐患是数据集的合并问题，
如果多个数据库的数据需要合并，由于编号重复，会给合并工作带来极大的困难。
（2）最大值加1，每次从业务表里获得最大的编号，然后加1作为下一条记录的主键。这种方案同样有
数据合并困难的隐患。且由于每次都要计算最大值，存在性能和并发的问题。
（3）自制加1，这种方案是最大值加1方案的改进，它建立一个专门的表来维护最大值，从而提高了性能。
这种方案同样有数据合并困难的隐患，并且有并发问题。
（4）全局唯一标识符GUID
GUID是由32位字符组成的全球唯一标识号，由特殊的算法来保证其计算结果的唯一性。
GUID计算不依赖具体的数据库产品，也没有并发的问题。因为GUID值是全球唯一的，
所以也不存在数据合并时主键冲突的问题。这种方案的缺点是: 占用存储空间，可读性、表意性差。
五、数据库设计其它技巧
1、通俗地理解三个范式
第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解；
第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；
第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。
没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑
。降低范式就是增加字段，允许冗余。
2、要正确识别与处理多对多的关系
若两个实体之间存在多对多的关系，则应消除这种关系。具体消除方法是：在两者之间增加第三个实体。
这样，原来一个多对多的关系，现在变为两个一对多的关系。例如用户与角色的关系。
3、提高数据库运行效率的办法
(1) 在数据库物理设计时，降低范式，增加冗余, 少用触发器, 多用存储过程。
(2) 当计算非常复杂、而且记录条数非常巨大时(例如一千万条)，复杂计算要先在数据库外面，
以文件系统方式用程序语言计算处理完成之后，最后才入库追加到表中去。
(3) 发现某个表的记录太多，例 如超过一千万条，则要对该表进行水平分割。水平分割的做法是，
以该表主键PK的某个值为界线，将该表的记录水平分割为两个表。
(4）若发现某个表的字段太多，例如超过八十个，则垂直分割该表，将原来的一个表分解为两个表。
(5) 对数据库管理系统DBMS进行系统优化，即优化各种系统参数，如缓冲区个数。
(6) 在使用面向数据的SQL语言进行程序设计时，尽量采取优化算法。