由于最近天天加班,连载可能会延迟了,希望大家莫要见怪,不过我仍然是会抽空看书并添加的。
努力努力
为了那句:今天不努力工作,明天努力找工作
Submitted by gouki on 2008, October 17, 9:14 AM
由于最近天天加班,连载可能会延迟了,希望大家莫要见怪,不过我仍然是会抽空看书并添加的。
努力努力
为了那句:今天不努力工作,明天努力找工作
Submitted by gouki on 2008, October 6, 11:59 PM
三大范式:第一范式,第二范式,第三范式,听着名字就很恐怖。但其实现在的人都被这个所谓的第三范式折腾死了,有事没事就拿出来涮涮,究竟怎么理解这些呢?一个一个慢慢的介绍。
数据库理论家们为数据库的设计1对N,N对N这种问题总结出了一个通用的解决方案,只需一步一步地三个范式(Normal Form)的规则应用到自己的数据库上就可以了。
第一范式的规则:
1、内容相似的数据必须“消除”(所谓消除,即再创建一个表来存储他们)
2、必须为每一组相关数组分别创建一个数据表
3、每条数据记录必须用一个主键来标识
第一条规则,看上去就比较适用于1对多的情况
第二条规则就不太好控制了,很多人认为第二条规则很难理解,数据的相关度,很难简单的描述清楚
第三条规则其实是一个实践经验,它的意思是数据表里的第一个数据行都应该包括一个独一无二的标识符作为索引。在使用MYSQL的时候,我们大多采用了自增字段来作为主键,但并非只有整数的自增字段才能作为索引,只要是独一无二的数据列,都可以用来做索引,之所以采用自增列,那是因为:1、不需要主动插入值2、整数列的时间和空间效率相对比其他类型的要高。
第二范式的规则:
1、只要数据列里的内容出现重复,就意味着应该把数据表拆分为多个子表
2、拆分形成的数据表必须用外键关联起来
第二范式,其实是在第一范式的基础上再进行一个拆分。指的就是第一范式规则的第二条内容。
外键关系在第二范式里显得特别重要,是因为第二范式时,数据会拆得更细,如果没有外键关联,恐怕数据就找不回来了。外键相当于我们日常所说的:交叉引用,对开发人员来说相当于指针。
第三范式的规则
第三范式只有一条规则:与主键没有直接关系的数据列必须“消除”
其实也就是把第二范式再分解,再建表。
可想而知,等到真正把一堆数据完全按照第三范式来进行设计的时候,恐怕在数据库里也就只能看到一堆ID了,数据呢?数据在哪里?通过外键,外键的外键,外键的外键的外键来慢慢的一个一个搜索吧。
对于MYSQL 4.1以下的版本,第三范式是会要了他们的命的,foreign key功能的不完善,让MYSQL 4.1以下版本,基本不适合第三范式,能用到第二范式设计时,数据表的效率已经几乎不能保证了。
这三个范式是著名学者E.F.Codd最先提出来的,后人在此基础 上对大到数学集合理论、小到关系数据库设计细节等诸多方面进行了研究和探索。如果对这方面有兴趣的朋友,还是多找找相关的书籍看看为好。
如果你的性子比较急,那么你可以尝试按照下面的方法来进行:
1、设计数据库的时候,一定要给自己充足的时间,如果等到数据库充满了数据,而程序也几乎开发完毕时,才发现数据库设计有缺陷,那么花费的代价就太大了
2、如果发现自己创建的表的数据列有序号,如name1,name2等,那一般就意味着还有更好的解决方案没有采用。可以考虑多创建一个表,而把这些分拆开。
3、第一时间往数据库里多插点测试数据,如果发现冗余量很大,往往就是表需要分拆的信号
4、设计时应该注意数据与数据之间的关联及引用关系
5、对于设计完的数据库,应该自己尝试写SQL语句,看看能否达到你预想的目标,如果达不到,那就要考虑是否设计的有问题。
6、如果你还是等不急,根据你的需要,到网上找找有没有类似的示例数据库,可以考虑拿来作借鉴。
说了这么多时间的范式,最后再说说他们的优缺点吧
缺点:数据表的个数越多,也就相对证明了从表单里获取数据并往表里插的时候,复杂性非常大,给开发人员会带来很大的困扰。同样,表多了,查询结果时,从中提取相关数据生成查询结果的复杂性也就越大;数据库的容量随着表的拆分量的增大而增大(不过现在也不是什么矛盾了,硬盘的价格几乎也快到了白菜价了,这点可以被忽略)
优点:严格按照范式设计出来的数据库,能够提供最丰富、最灵活的查询选项,人们往往都是在等到必须使用一种新的查询或者必须对数据进行一种新的分类时才会真正意识到这一点,但可惜的是,这些新需求往往都是出现在数据库已投入运行数月之后,到时候再改数据库,代价非常大。
现在工作有点忙,连载不会忘记,但更新频率会放慢,毕竟全部都是手工打出来的字。
Submitted by gouki on 2008, October 3, 7:06 AM
一个好的数据库设计应该符合以下几点要求:
1、数据表里没有重复冗余的数据(如果总是往里面插入同样的数据,那应该是设计上有问题,当然现在在利用空间换时间的时候,多数人还是保留了这样的想法)
2、数据表里没有column1,column2,column3……这类没有明确意义的字段,因为这样会让后来人摸不清头脑
3、数据表占用的空间越小越好
4、使用频率高的数据表的查询,应该都能以简单高效的方式执行(表内数据少的时候,你就是10几个left join,你可能都感觉不出什么,但数据量一大,你一个left join都会让你感觉到速度慢下来,如果最初设计时没有满足这个要求,那么,以后想改可能也没有机会了)
这些也只是一些总的原则,也只是简单的介绍,以后会详细说明,当然上面这几点并非完全正确,就象第三范式,这是一个标准,但这个标准真的就是最好的吗?并非如此,但我们现在是在讲设计数据库,它好不好,目前不讲。以后一起讨论
为MYSQL的数据库和数据表甚至字段起名字还是有讲究的,最重要的是,千万不要使用保留关键字,而且有一些单词很奇怪,在4.0里面并不是关键字,但升级后,却变成了关键字。
详细的关键字列表请看:MYSQL手册中保留字部分
对于一个完整的设计应该注意以下几项:
1、由于MYSQL对数据列的命名不区分大小写,而对库名和表名区分大小写,因此为了规范和统一,请使用同样的规则,不要象程序代码那样来个骆驼命名啥的,这样只会给开发带来困难,建议是全部采用小写,移植、升级都方便
2、不要采用特殊字符或者中文,MYSQL对于多字节的处理并不十分完美,虽然支持中文建库、建表等,但实在不建议使用,如果你的服务器对中文支持不好,可能建库的时候就会是乱码,字段里,明明看到有值就是查不出,所以,为了规范,还是采用英文,26个字母的排列组合,没有那么复杂的。
3、数据库、表、字段的长度请不要超过64个字符,
4、表名和数据列名,请尽量采用有意义的名称,不要出现上文提到的那种column1,colnmn2之类的,时间长了,你自己都可能不知道是什么意思
5、给字段命名,需要有规范,因为这样会减少粗心带来的错误,比如username,user_name,如果分在各个表里,恐怕你每次写程序的时候,都得再检查一遍吧?对于由多个单词组成的字段,要么全部加下划线,要么全部不加,这样也比较有利于开发和维护
6、数据列的单复数,原因和5一样,要么全部单数,要么全部复数,一会单数一会复数的,开发和维护的时候,你就得盯着数据表来进行了。
数据库的设计是一件很复杂的事情,要在短时间内把一批数据分割开,并存储到数据库中,还得为开发人员提供足够的优化空间,不是一天两天就能完成的,当然现在有很多这样的工具,比如powerdesign(PD),在设计完后,还能导出数据库,确实是挺方便,但这样的软件,价格就太高了,不是我们所买得起的。
平时,我们还是使用WPS的电子表格,或者openoffice的电子表格功能,设计好数据表(电子表格最大的好处就是有几乎无穷的sheet,可以让你把一个很大的库放在这些sheet里),而且,几乎每台电脑上都会有这样的工具,便于交流。这样可以在最初的阶段对于一些数据列进行安排(没办法建立索引的,只是简单的用来布局,检查设计上是否有缺陷)
对于管理MYSQL,也有很多工具,比较常见的,就是:phpMyadmin;MYSQL自已也提供过,好象是mysqlFront?记不太清,现在我自己用的是navicat for mysql lite ,不用钱的东西都是好的。虽然在国内,大家都了解软件业的行情。自己也处于软件业的下游,能够使用正版,还是使用一下正版吧。不能使用正版的,找找免费版。
在我看的书上,它介绍说openoffice里其实还隐藏着连接数据库这个功能的,而且可以能够象创建视图一样来创建SQL,这个功能不错,我以后要好好看看,如果确实有用,那我WPS也不装了,直接使用openoffice。
不过,最常用的,最方便的,还是使用phpmyadmin,它实在是居家旅行、杀人灭口之大杀器。
Submitted by gouki on 2008, September 27, 12:17 AM
本来觉得二进制字段没有什么好介绍的,本来嘛,二进制字段,不就是xxxtext变成了xxxblob?长度,大小都没有变化,只是存储的类型变成了二进制,如果把那些xxxtext字段的属性加一个binary,那就和xxxblob差不多了。
只是在没有加上binary属性的时候,xxxText字段的排序和比较是按字符串类型处理,而xxxBlob是按二进制处理的。加了BINARY属性自然是一样的。
关于在数据库里存在BLOB信息,历来就是一个有争议的话题。最早的VBB论坛就是把附件存在数据库里的,后来还有人单独做HACK把附件剥出来。很多人认为数据库就应该存储一些文本信息,对于二进制数据(图像、附件等)就只应该存储链接,而把文件单独存储出去。这样可以更加有效的利用数据库的空间。
但支持把附件存储在数据库的人却认为,二进制数据存储在数据库内,有利于数据的迁移、备份,提高了数据的集成程度,而且在程序里也能够使用统一的形式访问数据。把常用的数据和这些二进制数据存储在同一个表内,一般被DBA们所痛恨,因为这会导致所有的数据记录的存取速度变慢,而且BLOB数据在正常操作情况下只能作为一个整体来读出。也就是说如果一个BLOB数据长度是1024KB,如果你仅仅想读最后那24KB的内容,没有直接的办法,只能先读出来,然后再定位到最后,BLOB数据只能以一个整体来读写和传输。
从5.0.3开始,原来的BIT型字段正式变形,成为二进制字段了,它的最大宽度达到了64,为了这个BIT型字段,MYSQL还特地增加了一条用来写出二进制数据的新语法:b'0101',SELECT查询的时候,遇到BIT型,将返回二进制数据。(我没有5.0.3的版本,没有测试过怎么读取,书上介绍,可以先使用 seelct bit_field + 0 命令把二进制转为整数,再使用select bin(bit_field + 0 ) 将这些整数显示为二进制)
对于二进制来说,数据会有溢出现象,它分为上溢出和下溢出,但不管是如何的溢出,只要是溢出了,所有的二进制位都将被设置为1。例如将-1,0,1,7,8五个数字依次存入BIT(3)数据列的时候,实际存放的是b'111',b'000',b'001',b'111',b'111'。
除开这些二进制字段,剩下的就是具有MYSQL特色的字段了,如果没有什么必要,确实不太建议使用,因为其他的数据库都不支持这两种类型,一旦在数据迁移的时候,很有可能会造成丢失或增大工作量,是什么字段呢?他们就是ENUM和SET(枚举和集合)。
对于MYSQL来说,这两种字段对于涉及字符的操作,有很高的效率,表面上存储的可能是文本,但在实际处理的时候,是按设置的下标来进行操作,即按INT类型操作,所以效率极高。
ENUM是一个字符串集合,它的成员最多可以有65535个,ENUM字 取值只能是这个集合中的某一个成员(不允许是不同成员的一个组合 ),相当于数学意义上的“排列”。
而SET虽然采用了类似的思路,但允许数据表中的SET字段的取值是集合成员的任意组合(组合数量不得超过64个),相当于数学意义上的“组合”。在内部,这些字符串分别与2的幂(1,2,4,8等)相对应,所以字符串的组合就相当于二进制位的组合 。因为每个安符串分别对应一个二进制位,所以SET类型的空间战胜比ENUM大。
虽然这两种类型的效率相对较高,但由于和其他数据库的不兼容性,因此多创建一个关联数据表来关联这些数据才是更有实用价值。
介绍完MYSQL所支持的所有字段的属性,也该介绍一些在创建数据列的时候涉及到的属性,注意,有一些属性只能用于特定的数据类型
属性名 | 含义 |
NULL | 数据列可以NULL值(一般是默认设置) |
NOT NULL | 不允许包含NULL值(因为bTree索引不支持NULL) |
DEFAULT xxx | 如果输入时没有指定值,则默认以xxx为值 |
DEFAULT CURRENT_TIMESTAMP | 这个在介绍日期时间类型的时候介绍过,默认插入当前时间 |
ON UPDATE CURRENT_TIMESTAMP | 在数据更新的时候,自动更新为当前时间 |
PRIMARY KEY | 定义为主键 |
AUTO_INCREMENT | 自动输入一个序列编号,只能用于整数类型的数据列,一般与主键对应使用,必须与NOT NULL,或UNIQUE 属性同时使用 |
UNSIGNED | 无符号整数,值得注意的是,无论怎么计算,即使是1-2,返回的也是无符号的整数 |
CHARACTER SET name | 仅适用于字符串列,指定一种字符集和一种可选排序方式 |
虽然MYSQL有DEFAULT XXX这种属性,但实际上,MYSQL并不允许使用函数来设定默认值,比如DEFAULT rand()就不被允许了。
介绍完这些,以后就该介绍数据库的设计技巧了。之所以在介绍设计技巧之前连载了这么长时间的数据类型,是因为在设计中,使用合适的类型可以适当的增加效率,具体的还是看设计吧。
Submitted by gouki on 2008, September 23, 11:29 PM
字符串,恐怕应该算是MYSQL里面最复杂的类型了吧?几乎目前所有的问题,都是出在与字符有关的数据列上,大致有几种
1、字符串的查询(以下如果不特指,都是指中文),搜索一个中文的时候,不管是模糊还是精确,往往结果都会有与搜索内容不一致的数据在里面
2、编码,现在大家都知道MYSQL连接上后,先执行一下mysql_query('set names GBK',$conn)这类的语句,从MYSQL4.0升级到4.1及以上版本的朋友在这上面吃的苦不少了。网上关于这类的提问也是最多的
3、索引、效率,varchar是MYSQL所特有的字段,而且长度可变,char则是固定长度的字符串。
在MYSQL所支持的几个字符串格式里面,char和varchar是用的最多的,char是定长字段,,也就是说,不管字符串的实际长度有多少,CHAR(10)将永远占用10个字节。字符串如果前端有空格,那么在存储的时候会自动被数据库去掉,相当于先执行trim($string),再进行存储,如果不满10个字节,将会采用空格填满,读取数据时,MYSQL会自动将这些空格去掉。看到这里,恐怕它的缺点之一就明显的暴露了,CHAR不能存储那些结尾确实有空格的字符串(因为读取时会被MYSQL自动去掉)。
数据类型 | 含义 |
char(n) | 固定长度的字符串,最多255个字符 |
varchar(n) | 可变长度字符串,最多255个字符(MYSQL<5.0.3,n<=255 , mysql>=5.0.3,n<=65535) |
tinytext | 可变长度字符串,最多255 |
text | 可变长度字符串,最多65535-1 |
medinumtext | 可变长度字符串,最多16,777,216-1 |
longtext | 可变长度字符串,最多4,294,967,296-1 |