范式：http://www.cnblogs.com/careyson/archive/2010/02/16/1668803.html
简介
数据库范式在数据库设计中的地位一直很暧昧，教科书中对于数据库范式倒是都给出了学术性的定义，但实际应用中范式的应用却不甚乐观，这篇文章会用简单的语言和一个简单的数据库DEMO将一个不符合范式的数据库一步步从第一范式实现到第四范式。
范式的目标
应用数据库范式可以带来许多好处，但是最重要的好处归结为三点：
1.减少数据冗余（这是最主要的好处，其他好处都是由此而附带的）
2.消除异常（插入异常，更新异常，删除异常）
3.让数据组织的更加和谐…
但剑是双刃的，应用数据库范式同样也会带来弊端，这会在文章后面说到。
什么是范式
简单的说，范式是为了消除重复数据减少冗余数据，从而让数据库内的数据更好的组织，让磁盘空间得到更有效利用的一种标准化标准，满足高等级的范式的先决条件是满足低等级范式。(比如满足2nf一定满足1nf)
DEMO
让我们先从一个未经范式化的表看起,表如下：
先对表做一个简单说明，employeeId是员工id,departmentName是部门名称，job代表岗位，jobDescription是岗位说明，skill是员工技能，departmentDescription是部门说明，address是员工住址
对表进行第一范式(1NF)
如果一个关系模式R的所有属性都是不可分的基本数据项，则R∈1NF。
简单的说,第一范式就是每一个属性都不可再分。不符合第一范式则不能称为关系数据库。对于上表，不难看出Address是可以再分的，比如”北京市XX路XX小区XX号”，着显然不符合第一范式，对其应用第一范式则需要将此属性分解到另一个表,如下:
对表进行第二范式(2NF)
若关系模式R∈1NF，并且每一个非主属性都完全函数依赖于R的码，则R∈2NF
简单的说，是表中的属性必须完全依赖于全部主键，所以只有一个主键的表如果符合第一范式，那一定是第二范式，而不是部分主键。这样做的目的是进一步减少插入异常和更新异常。在上表中，departmentDescription是由DepartmentName所决定，但却不能由EmployeeID决定，故要departmentDescription对主键是部分依赖，对其应用第二范式如下表：
对表进行第三范式(3NF)
关系模式R<U，F> 中若不存在这样的码X、属性组Y及非主属性Z（Z Y）, 使得X→Y，Y→Z，成立，则称R<U，F> ∈ 3NF。
简单的说，第三范式是为了消除数据库中关键字之间的依赖关系，在上面经过第二范式化的表中，可以看出jobDescription(岗位职责)是由job(岗位)所决定，则jobDescription依赖于job,可以看出这不符合第三范式，对表进行第三范式后的关系图为：
上表中，已经不存在数据库属性互相依赖的问题，所以符合第三范式
对表进行BC范式(BCNF)
设关系模式R<U，F>∈1NF，如果对于R的每个函数依赖X→Y，若Y不属于X，则X必含有候选码，那么R∈BCNF。
简单的说，bc范式是在第三范式的基础上的一种特殊情况，既每个表中只有一个候选键（在一个数据库中每行的值都不相同，则可称为候选键），在上面第三范式的noNf表中可以看出，每一个员工的email都是唯一的（难道两个人用同一个email??）则，此表不符合bc范式，对其进行bc范式化后的关系图为:
对表进行第四范式(4NF)
关系模式R<U，F>∈1NF，如果对于R的每个非平凡多值依赖X→→Y（Y X），X都含有候选码，则R∈4NF。
简单的说，第四范式是消除表中的多值依赖，也就是说可以减少维护数据一致性的工作。对于上面bc范式化的表中，对于员工的skill，两个可能的值是”C#,sql,javascript”和“C#，UML,Ruby”,可以看出，这个数据库属性存在多个值，这就可能造成数据库内容不一致的问题，比如第一个值写的是”C#”,而第二个值写的是”C#.net”,解决办法是将多值属性放入一个新表，则第四范式化后的关系图如下：
而对于skill表则可能的值为:
总结
上面对于数据库范式进行分解的过程中不难看出，应用的范式登记越高，则表越多。表多会带来很多问题：
1 查询时要连接多个表，增加了查询的复杂度
2 查询时需要连接多个表，降低了数据库查询性能
而现在的情况，磁盘空间成本基本可以忽略不计，所以数据冗余所造成的问题也并不是应用数据库范式的理由。
因此，并不是应用的范式越高越好，要看实际情况而定。第三范式已经很大程度上减少了数据冗余，并且减少了造成插入异常，更新异常，和删除异常了。我个人观点认为，大多数情况应用到第三范式已经足够，在一定情况下第二范式也是可以的。
由于本人对数据库研究还处于初级阶段，所以上述如有不当之处，还望高手不吝指教…
By CareySon
——————————————————————————————————————————————————————
索引：http://www.hudong.com/wiki/数据库索引
索引的主要目的是加入访问数据的速度
根据数据库的功能，可以在数据库设计器中创建三种索引
唯一索引
唯一索引是不允许其中任何两行具有相同索引值的索引。
主键索引
数据库表经常有一列或列组合，其值唯一标识表中的每一行。该列称为表的主键。
聚集索引
在聚集索引中，表中行的物理顺序与键值的逻辑（索引）顺序相同。一个表只能包含一个聚集索引。
如果某索引不是聚集索引，则表中行的物理顺序与键值的逻辑顺序不匹配。与非聚集索引相比，聚集索引通常提供更快的数据访问速度。
建立索引 CREATE INDEX mytable_categoryid_userid ON mytable(category_id,user_id);
使用数据库索引时，不需要在SQL语句中明确说明。
在刚开始的时候，如果表不大，没有必要作索引，意见是在需要的时候才作索引。
————————————————————————————————————————————————————————
存储过程：http://zh.wikipedia.org/zh-cn/存储过程
预存程序 (Stored Procedure)，又可称存储程序或预储程序或者存储过程，是一种在数据库中存储复杂程序，以便外部程序调用的一种数据库对象，它可以视为数据库中的一种函数或子程序。
预存程序具有下列的好处：
预存程序可以用在数据检验，强制实行商业逻辑等。
预存程序是数据库对象之一，必须使用数据定义语言来创建，
- 以下示例，以Microsoft的SQL Server所以采用的T-SQL语法表示。
-
1 CREATE PROCEDURE usp_AddProduct
2 (
3 @Barcode varchar(13),
4 @Caption nvarchar(50)
5 )
6 AS
7 BEGIN
8
9 IF LEN(@Barcode) < 13
10 RAISERROR('Barcode length is too short.')
11
12 INSERT INTO MyProducts (Barcode, Caption) VALUES (@Barcode, @Caption)
13 END
外部程序需要使用 EXECUTE 或 CALL 来调用预存程序。
EXEC usp_AddProduct '2293891100011', 'MyProductCaption'
————————————————————————————————————————————————————
级联删除：http://www.51testing.com/?uid-182741-action-viewspace-itemid-95001
如果父表没有删除就删除子表（引用父表的字段），那么系统会报错。
如何级联删除呢？
外键要加上ON DELETE CASCADE选项，那么在delete语句的末尾加上CASCADE，就可以实现两张表的级删除：
因为不同数据库的原因，有的数据库不能实现直接删除父表。
以下是ON DELETE的官方解释：
ON DELETE
The ON DELETE clause indicates that when a DELETE is executed on a referenced row in the referenced table, one of the following actions will be executed upon the constrained column, as specified by action:NO ACTION(default)
The NO ACTION clause produces an error if the reference is violated. This is the default if action is not specified.CASCADE
The CASCADE keyword removes all rows which reference the deleted row. Exercise caution with this action.SET NULL
The SET NULL clause assigns a NULL value to all referenced column values.