易栈网-膘叔

将数据库转为范式的过程中，需要把一系列数据表关联起来，这种关联用数据库术语来说就是“关系”。一般来说，两个数据表之间的关系大致有三种：
1、1：1关系。两个表之间是1：1,代表了第一个数据表里的每一条记录分别对应着第二个数据表里的一条记录，同时第二个表的记录也分别对应着第一个表中的一条记录，实际工作中，很少见到这种关系，因为既然是1：1,那么证明他们是可以合并为一张表的（但在WEB处理的时候就不是这样，比如用户基本信息，用户扩展信息，他们肯定是1：1的，但如果扩展信息中有TEXT字段，而用户信息又经常被读取，那么我们就会把经常读取的字段分为一张表，不是经常读取的或者是含有TEXT内容的字段分拆为另外一张表，以加快读取速度。）
2、1：N关系。两个表之间是1：N，代表第一个数据表里的一条数据可以对应着第二个数据表里的多条记录。（大多数举例都是用工厂和产品来进行举例，从WEB方面来说，我们可以从用户表来分析，一个用户可以有多条地址簿，家庭、工作单位等，看淘宝在下单时选择地址就知道了）
3、N：M关系。两个表之间是N：M时，代表第一个数据表的一条记录可以对应着第二个数据表里的多条数据记录。同时第二个表中某条记录也可以对应着第一个数据表的多条记录。这里一般是用订单来做介绍：一个订单可以购买多个产品，一个产品也可能存在于多个订单中。

1：1关系
这种类型的表起源通常因为人们把某个数据表拆分成两个使用同一个主键的数据表。把1：1表分拆大致有两种原因，一种是信息安全方面考虑，还有一种就是上文说的效率方面的考虑。

1：N关系
1：N关系是最常见的两表之间的关系了。只要在第一个表的数据记录里有一个特定字段引用了第二个表中的数据列，就会形成1：N关系。
一般来说，1：N有点象1：1表，大多数情况下都是采用主键关联，只有这样才会保证1：N，而不是N：M，例如：分类表与文章表、用户表与地址簿表，论坛主题与跟贴，用户表与订单表，员工表与员工履历表等，这些都属于1：1表。

N：M关系
其实1：N在设计的不太好时，很容易就会变成N：M表。N：N表大致用于订单与产品、用户表与回贴表、员工表与考勤表等等

当你需要把分类表显示为树形时，肯定是需要进行一些妥协，就象前面文章中所说的，对数据进行这种处理意味着要无数的SQL查询命令或者复杂的客户端代码打交道。
可供选择的解决方案之一是在分类表中增加两列：sort,deepth,SORT字段负责给出各条数据记录将出现在层次关系树的第几行（假设同一层次的记录将分类名进行排序），DEEPTH字段则负责该分类所在的层次深度。
这种方式的好处是可以通过在MYSQL程序中执行下面这条简单查询的办法得到证明。例如：SELECT CONCAT( SPACE(deepth * 2) ,catename ) as category , sort , deepth FROM categories ORDER BY sort.其中concat函数的功能是把两个字符串并为一个，space函数的功能是生成指定个数的空格字符，AS关键字是给整个表达式起一个新的名字(别名，可能更容易理解一些)。
执行这样的SQL后，可以生成一个简单的树结构，树的尝试都是通过deepth的空格来显示的（这里显示简单的例子）
CATENAME　　　　　　　　　　SORT　　　　DEEPTH
主分类　　　　　　　　　　　　０　　　　　　　０
一级分类　　　　　　　　　　１　　　　　　　１
二级分类　　　　　　　　　２　　　　　　　２
重复一级分类　　　　　　　　　３　　　　　　　１
重复二级分类　　　　　　　　　４　　　　　　　２
三级分类　　　　　　　　　　　５　　　　　　　３
大致结构如上。
那么sort值和deepth的值是怎么来的呢？我们会进行一个简单的演示：
1、新建一个[新的三级分类]，它被插入到[二级分类]下一级。而二级分类有关的数据是sort=2,deepth=2
2、那么我们首先要找到[二级分类]下是否已经有数据插入，SQL为：WHERE parentId = [二级分类]ID
3、将数据追加到二级分类下（即SORT+1,深度=）
4、更新相关数值
在这里面就涉及到一些问题，二级分类下如果有多个三级分类，三级分类还有四级分类，这时候SORT值的取值就比较难以控制。插入值后，它的SORT值其实是覆盖了原来的重复一级分类的SORT，那么，原来的SORT值>＝当前SORT值的，都需要自动加1.
由此可见，虽然SORT值和DEEPTH值简化了查询工作，但实际上他的写操作变得频繁和复杂了。如果需要更新其中的一条记录，所涉及的操作还会更多。因为他必须要相应的调整sort值和deepth值。
因此，在实际情况中，你必须决定是对读操作进行优化还是对写操作进行优化。一般情况下，对于这种分类表，我都比较倾向于一次读出，然后利用 PHP语言进行深度的处理 也就是说，我是一般不会用SORT和DEEPTH字段的。因为大多数情况下，分类表都是一种比较固定的表，不大会读写，而在后台的读写，也不会影响到前台的操作。。

好象有点乱。

分类表是一种典型的层次化关系的表，从数据库设计工作的角度看，让每个分类记录的parentId字段指向它们父分类的Id即可。
把层次关系转化为数据表并不困难，而且层次还相对比较清晰，但在这种表面现象的背后还有许多难题在等待着用户解决。比如，我们无法只用一个简单的SELECT就把指定分类的父分类或者子分类全部查询出来，而必须通过多次查询才能解决这个问题（或者一次查出后，用程序来进行处理）。
事实上，数据库设计和SQL编程有着千丝万缕的联系，很难将他们完全区分开来，再者，如果SQL不足以把想要查询的数据从数据表里提取出来，那么，想拿出一个优秀的数据为设计方案就只能是一句空谈。
想要通过数据表去管理和使用层次关系，得解决很多难题，而这些难题几乎都与SQL语言不能递归查询这一事实有关。以分类表为例：
1、只用一个查询就把指定分类的所有父分类全部查出来是不可能的
2、把完整的数据表还原为层次关系（树状）也是一个难点，还是必须执行多次SQL才能完成。
3、把指定分类下所有子分类全部查询出来
4、设计时，一个分类不能有两个父分类（例如：sql语言既能够放在database分类中，但好象放在programming分类下也行，因此，如果sql语言有两个父分类仿佛才是合理的）
5、层次关系最担心 的是留下循环引用隐患（比如手工删除数据或者添加数据时，很容易导致第4条的情况发生，数据库层次断链或者重复等）
虽然有这些存在的问题，但并非不可解决，而从上面这些难点来说，层次关系往往会导致即使是一个相对简单的问题也需要很多条SQL查询才能得出答案，而且整个过程都相当慢。如果不使用层次关系（或者使用有限的层次关系），上述问题即都可以避免。如果必须使用多级的层次关系，增 加一些数据列或数据表来提供更多关于层次关系的信息，将有助于层次关系的解决方案变得简单一些。
从范式的标准来说，冗余是不对的，它会导致存储空间不必要的浪费，增加数据库内部管理工作的负担，但为了提高应用程序的执行效率，冗余反而是一种相当简明的解决方案，因此，数据库设计其实是一件多方妥协和折中的事。在数据库领域，通往同一个目标的道路往往有好多条，选择其中的任意一条，都意味着作出了这样或那样的妥协。做出什么样的妥协最有利这往往取决于数据库的具体使用情况：什么类型的查询发生的最为频繁？数据需不需要频繁修改？

好久好久没有写了。。。重拾起来，确实有点困难，不过，这次是坚持了。

关系数据库的三个范式最早是著名学者E.F.Codd提出来的，后人又在此基础上对大到数学集合理论，小到加设计细节等诸多方面进行了研究和探索。
有些数据库类图书在介绍三个范式时，又在其基础上增加了一些所谓的范式，但这些范式在实践中重要性不大。他们及其相应的规则只是把标准三个范式的所做的事情描述的更细致而己，这些充斥着“实体”、“属性”等专业术语却又彼此大致雷同的教条不仅没有把事情说清楚，反而会让人们更看不出它们与加有什么联系。
如果确实对数据库非常感兴趣，有一些书值得读读（我没有读过，但我现在看的书的原作者推荐）："SQL for smarties","The Practical SQL handbook","Database for mere mortals","SQL-99 complete,really"
当然如果你对读这些书的意向不大（我也意向不大，英文的，估计看不懂），那么如何很快就能上手呢？这里有一些简单的方法：
1、在设计数据库的时候，一定要给自己以充足的时间，如果数据库里已经充满了数据，而且配套的程序也已经开发完成的时候，再发现数据库设计方案还需要修改，那么花费的时间和精力可就太大了
2、如果发现自己给数据列起的名字中有序号，比如field1,field2之类的，则应该提高警惕，这种现象几乎上增加了 是意味着还有更好的解决方案没有想到——再多创建一个数据表
3、在第一时间向数据库输入一些测试用途的数据，而且要尽可能地多包括一些特殊情况，如果数据出现冗余，往往是应该把数据表拆分 的提示信号（但有时候也未必，比如用空间换时间的时候就需要冗余，这点在WEB应用上尤其明显）
4、注意发现和运用各个数据表之间的关联/引用关系
5、掌握SQL语言。缺少SQL编程经验的人是很验证拿出一个优秀数据库设计方案的。把信息存入数据库的目的是为了让更多人能够使用SQL查询命令把它们再迅速准备地查出来。只有了解了SQL查询命令的涉及范围，才能找出把数据分门别类地存入数据库的最佳办法
6、找个示例数据库做为借鉴（这个相对比较重要，比如你要开发论坛程序，那么你应该先找一些开源论坛进行安装，再对他们的数据库结构进行研究和借鉴是最快的学习方法）

原来的连载因为一些原因停了N久，从下周开始，每周继续连载。

这次，直至结束。
优化方面的事情以及MYSQL集群等，可能暂时不能涉及
仅涉及MYSQL最基本的一些资料，我想这也应该足够了吧？