Submitted by gouki on 2008, September 10, 3:55 PM
今天是一个伟大的日子：教师节，小时候每到这个节日，都会向教师送送贺卡什么的。如今离开学校N久，虽然也在上夜大，但人和人之间的关系却变得淡漠了。
翻开几年前写的东西：
教师的悲哀
- 多少年来，老师给我们的印象一直是为人师表，传道解惑的崇高形象。随着这两年负面报道的逐渐增多，教师给我们的印象已经逐步改变。
- 新闻里的事迹不再是某某教师鞠躬尽瘁，相反却是某某老师象披着羊皮的狼，尽做着一些道貌岸然的事情。
- 其实就我自己而言，在我长大至今，有一些老师对我还是比较照顾的，这种照顾不是简单的关心或者其他，有的时候打骂反而成了一种依赖，当然打骂也要看人的。也有一部分老师动不动就打骂学生，求学生涯中这类老师也不少见。
- 曾经有位老师在看到我一同学上课玩那种玩具手枪后，把他叫出教室，打了一记耳光，问学生，我打你应不应该，学生回答不应该，接着又是一记耳光，再问，现在是不是应该。学生比较倔，结果脸就被打肿了。而该老师却一副理所当然的样子。这样的老师我就遇到好几个。其中还有一个是看到学生不听话，拎起学生笔盒就砸学生头，靠墙的就揪住头发往墙上装，以至于当时全班学生没有人敢买金属笔盒的，就这种情况下，该老师还要用脚踢学生。老师的名字我就不提了，后来我再回学校有事的时候，发现该老师已是学校教导主任。
- 提起教导主任，又让我想起学校的一位为人师表的人来，可能是因为年龄比较大吧，打骂学生有点力不从心，就改为掐，学生的耳朵因此而。。。。。。哎，不想多提。
- 有的时候我就在想，这些人怎么会当上老师的？难道仅仅因为他们有一定的能力就可以做这些事情吗？他们怎么可以这么做？打是亲骂是爱的时代早就不复存在了，为什么还要这么对待学生，难道是因为他们以前也是这么受苦，现在是报复行为？
- 话虽是这么说，但真正关心学生的老师还是挺多的，上面举的只是学校中的一些败类吧。印象中深刻的几位老师是：郑平(小学语文老师)、徐湘(初中数学老师)、张XX(初中英语老师)、汤进(中专物理老师)，当然还有一些，只是自己愚鲁，而且记忆力不好，不再记得，只是依稀对他们的印象比较深刻。再多一份怀念 吧？
- 小时候学语文的时候，知道“桃李满天下”，更在屡见不鲜的作文里看到某老师退休后，经常有学生去看望他们，时不时的谈起学生时代的事情，往往哄笑一堂。如今，人的思想在进步，对教师的观念也在改变，如果教师仅仅只能传授知识，而无法在品德方面对学生有所教育的话，恐怕再也不会让学生有所相念了。
- 教师节又快到了，谨以此文献给那些关心过我和爱护过我的老师，同时希望他们能够平安一生。对那些刻薄的老师，也希望他们能够更好的关爱自己的学生，把学生当成自己的孩子来看待，才会得到更多的尊重。
- 一家之言。
- 老师，您珍重。
上面的内容是几年前写的，现在想想也算是想法和以前两样了。教师希望人成才，只是手法用的比较残忍而己。今年5·12的范跑跑教师让社会感到震惊，虽然他说出了实话，但得不到全国人民的理解，作为一个普通人，或许他这样没做，但是做为一个为人师表的老师，他这样带出来的学生，以后又怎能做到不自私自利呢？昨天收到手机新闻里的一条：说是现在教师上岗，师德将成为一个重要标准。说实话，师德，谁来评判？当那些教师拿着学生家长送的礼物或者其他时，即使他教的再好，算是有师德吗？不清楚。或许我又FQ了。
乱讲讲，乱讲讲，权当我在放狗屁
Tags: 教师节, 尊师重教, 节日, 感慨
Misc | 评论:0
| 阅读:19241
Submitted by gouki on 2008, September 11, 9:38 AM
前两天我们介绍了myisam和innodb两种类型的表结构，可是：to be or not to be ,that's a question。
在我的实际应用中，我到底应该选择哪个呢？用myisam还是innodb，确实是让人伤脑筋的问题。所幸，这两种表结构可以存在于同一个数据库中，DBA们也就可以根据实际应用来设计数据表是使用哪种类型的了。
虽然一般情况下认为myisam的存取速度超过innodb，但这也不是绝对的。确实innodb所占用的空间要比myisam大的多，但是相对的，innodb在存储数据时，是行锁定，而并非myisam的表锁定，所以，在这一点上，又不能说谁快谁慢了。
相对于安全性方面，innodb毫无疑问是首选，至少不用再担心多人同时操作表时会发生什么意外的状况了。可是从节约时间和空间上来选择，myisam又是远超innodb。
究竟应该选用哪种呢？实在是一个非常头疼的问题。所以说，一般情况下只能根据系统的需求来决定到底使用哪种类型的表结构。如果你为了追求速度，认为数据丢失一条两条无所谓，错误一下问题也不大，那么毋庸置疑，myisam是首选。如果需要用到事务，那innodb就是不得不选的。如果你实在没法确定需要哪种类型的表结构，那么，创建两个不同类型的表，逐步增加数据量的大小，多测试几个重要的SQL（以后系统中可能会使用的SQL），看看哪个效率更高就选择哪个。
虽然这些都是根据特性来选择的，但我们也不能忽略服务器自身的配置。如果服务器是8核、12G内存，却只用来处理一个小小的留言板，你还会在乎是使用哪种类型的表结构吗？
官方网站上也有关于这两种数据表在细节方面的优劣对比：http://dev.mysql.com/doc/mysql/en/innodb-restrictions.html
随便说说而己。。。明天继续介绍heap表和一些不常用的表结构类型。
Tags: mysql, innodb, myisam, 选择, 连载
DataBase | 评论:0
| 阅读:20789
Submitted by gouki on 2008, September 10, 9:36 AM
（今天晚上要读书，所以先发上来）
昨天我们讲的是myisam表的特性，今天我们来讲讲innodb的一些特性。
之所以要采用innodb，是因为innodb有一些新的特性，而这些特性又是myisam所不具备的，它们是：事务、数据行级锁定、外键约束、崩溃恢复
看到上面这些特性，你是不是基本了解了innodb所应用的范围了？是的，innodb所具备的这些特性，使得mysql即使在高端应用也有了用武之地，特别是在处理类似银行这些对事务非常关心，也非常重要的场合（存钱取钱以及转帐等），下面就对这些特性进行简单介绍。
在介绍特性之间，先说明一下，innodb虽然一直是MSYQL的集成组件之一，但事实上，innodb的驱动的研发和收费技术支持都是来自innodb公司：http://www.innodb.com，这可是一家独立的公司。
事务：在innodb里所有的操作都可以被看成是在执行一个事务，它允许把几条有内在逻辑关系的SQL当成一个整体来执行。所以执行期间发生错误，则所有的命令会全部失效，就好象从未执行过任何SQL一样，而不仅仅是导致错误的那一条命令。正因为这样，所以事务功能相对增强了数据库的安全性。mysql支持全部的4种事务级别（READ UNCOMMITTED,READ COMMITED,REPEATABLE READ , SERIALIZABLE）
数据行级锁定：在执行事务时，innodb表的驱动程序会使用内置的行级锁定机制，而不是采用mysql自身的行级锁定机制。也就是说即使在执行事务时，其他进程仍然可以访问它，因为被锁定的仅仅是那些正在接收事务处理的记录。这与mysql的lock table不一样，lock table执行完后，整个表都被锁定了。这两种方式的对比可以让你看出，如果有一大堆人在处理一个很大的数据表，孰优孰劣一看便知。并且，innodb的这个驱动相对比较先进的就是，它能够自动识别“死锁”（所谓死锁，就是两个进程各战胜一项对方需要的资源，同时又在等待对方先释放所占用的资源，结果导致两个进程都不能执行），并自动终止两个进程中的一个。这才是innodb的强项。
外键约束：如果在数据表间定义了关联，innodb驱动将自动保证数据表的引用一致性，即便在执行过delete后也能同样保持。也就是说，不可能出现在A表的记录引用B表一条并不存在的记录，这就是所谓的：外键约束
崩溃恢复：理论上，在数据库发生崩溃后，只要计算机的文件系统没有被破坏，innodb数据表能够迅速地自动恢复到一个稳定可用的状态。说明一下，这只是理论上，具体怎么样，我没有测试过，也没有搜索到相关文章，如果有人搜索到相关的资料，请告知，以便我更新一下，谢谢。
说了这么多的特性，下面也要谈谈它的缺点，毕竟凡事都有双面性，有优点自然也会存在缺点，否则，谁还会用myisam？
使用innodb有以下几个缺点:
1、表空间的管理。与myisam分成三个文件的存储方式不一样，innodb把所有的数据、索引、结构都存在了一个表空间里。当然，表空间可以是一个或多个文件组成，也就是说这些文件组成了一个虚拟的文件系统。然而问题就出在这里，这些文件被创建后只能增长，不能缩小。如果想复制innodb表，只有使用mysqldump来进行处理，而myisam在停掉数据库后，直接复制就可以了（好象到了4.1或5.0后，这样的直接复制好象不行了？我是指两个表的设置如果不一样的话）
2、数据记录的长度。innodb的单条记录最多占用8000个字节。这个限制不包括text和blob等类型字段，事实上，这此字段只有前512个字节和其他数据存在数据库里，超过这个长度的内容都是被存储在上面所说的“虚拟文件系统——表空间”的其他文件里面。在这里，有一个回复，也可以参考一下，虽然不一定完全正确：http://imysql.cn/node/548，呵呵。
3、存储空间。在内容相同的情况下，一般来说innodb所占用的空间要比myisam所占用的大的多，最多时，可能会有两倍。
4、全文索引。这恐怕是它最大的缺憾了，innodb不支持full-text index。
5、GIS数据。存储和读取这个，还是myisam来的更方便一点，所以innodb也不支持它。
6、COUNT相关。innodb在处理SELECT COUNT(*) FROM table的时候，比myisam慢得多，这主要是因为它支持事务。可是，我在用sql server的时候也没有慢很多嘛。不知道它何时能够被解决，否则在内容较大的时候，处理分页就烦了。
7、表锁定。因为innodb有自己的表锁定算法，所以想使用表锁定功能时，用innodb所支持的select .. for update或select .. IN share mode，而不要使用mysql 自带的lock table。
8、虽然有这么多好处，可惜mysql这张表，还是得用myisam格式。而不能使用innodb
9、费用。。。。对于我们个人来说，我们只需要使用免费的mysql，而不是使用商业版的mysql，那么收费就与我们无缘了。至于商业应用嘛，那，钱是少不了的，听说，如果在mysql许可证里加上innodb支持，将收取双倍费用。好恐怖。。。
上面的这些也是我在参考书本后，进行的整理，否则，凭我这些小小的经验，怎么可能了解这么多？
Tags: mysql, database, innodb, myisam, 连载
DataBase | 评论:0
| 阅读:22443
Submitted by gouki on 2008, September 9, 11:44 PM
从今天开始，逐步对MYSQL数据库的设计以及一些常规资料进行介绍。内容可能会参考网络或者书籍，当然还有自己的一些小小的经验。思维可能会有点跳跃，但可以肯定的是，本文没有一个字是从网上COPY下来，纯粹是手工输出。如果有错别字，请留言，我会尽快改正。
数据库应用程序的第一阶段往往都是对数据库进行设计，设计的好坏对应用程序执行效率的高低、程序的编写以及后期的维护工作的难易程序和能否在今后灵活修改设计方案等问题会产生巨大且深远的影响。因此，可以这么认为，在设计阶段埋下的隐患会在后期给开发者和使用者带来无穷的烦恼和痛苦，而这个，却没有任何捷径可走，数据库设计方案的好坏与设计者的知识和经验是否丰富有着很大的关系，如果单位有DBA的话，或许要担心的事会少一点，如果没有，黑黑，那就等着受苦吧。
事先说明，本人的设计能力也非常差，所以，在设计一块，我是绝对参照书本而写，即使有个人见解也不会太多。
要设计数据库，就不得不了解MYSQL数据表的一些基本类型，我在以前的文章里也介绍过，只是今天在这里我会介绍的更详细一点。MYSQL支持多种数据表类型，比较重要和使用的多的表类型是：myisam,innodb,heap三种。
如果在创建数据库的时候，没有指定表的类型，一定是根据mysql的配置文件中：default-table-type这个选项来决定的，基本上，大多数的设定都是myisam，也有可能是innodb，但几乎可以肯定不会是heap,如果有，那实在是太妖了。
今天有点晚了，先介绍一下myisam类型的表的特点吧，明天再介绍其他的。
myisam的最大特点就是成熟、稳定和易于管理，这种类型也是mysql所特有的。并且，如果没有其他什么特殊应用，如事务等，一般建议是选用这种类型的表结构。
虽然大家都了解myisam，并且在实际应用中也正在使用这种类型的表结构，但恐怕你不知道的是，即使是myisam结构，也会为三种类型：
1、myisam static(静态myisam),一般来说，如果数据表的数据列各自都有预先定义好的固定长度，服务器会自动选用这种类型。该类型的存储、读取效率非常高，即使是大量的CRUD操作（只是为了方便，因为R是读取，删了R的话，又是一个新名词，所以还是把R放在了里面）也是如此。同时，该类型的表结构安全性很高，即使出现文件受损或其他问题，数据记录的提取和恢复工作也比其他类型的数据表更容易。
2、myisam dynamic(动态myisam)，这个就相对比较好解释了，凡是数据表结构里有varchar字段的，服务器就会自动选用这种类型。优点是：与静态myisam相比，本类型所占用的数据空间会小上很多，在存储字符串和二字制数据时所需要的字节数也往往就是它们的实际长度（或许会额外多出几个字节的开销）。缺点是，这样会造成每行数据的记录长度会不一致，如果数据在进行更新或删除操作的时候，很容易就会在原先存储这些数据的地方形成空洞，造成空间的浪费，而且还会造成数据的不连续，并分散在各处。当数据碎片越来越多的时候，数据的存取时间也就会越来越长。因此，就有了一个单独的方法：optimize table或者其他专门的工具来对数据表进行优化
3、myisam compressed(压缩型myisam)，以上两种类型都可以使用myisamchk工具进行压缩，一般来说，压缩后的数据库占用空间大多仅为原来大小的一半（当然这也于数据库存储的内容有关）。虽然以后在读取他们的时候需要先进行解压缩操作，但在“低速硬盘+高速CPU”的系统上，数据表的访问会变得极快。然而，这种类型的表有一个非常致命的缺点，即它们是只读的，不能进行任何写操作。
今天先介绍到这里，明天继续往下讲。希望会给大家带来帮助。
Tags: mysql, 数据库, 设计, 表的类型, 连载
DataBase | 评论:1
| 阅读:23293
Submitted by gouki on 2008, September 9, 11:13 PM
其实我要讲的并非什么大道理，而是我在读者上看到的一篇文章。内容大概讲的是文章作者（简称作者）乘大巴回杭州，让大巴司机在城北的某个路口放他下来——因为如果乘到终点站，那他到家的路程比从那个路口回到家中的路程远的多。
刚下车，就有一出租车过来。上车后，司机说：这路口每天晚上都有从大巴下来的顾客，在这里等是一等一个准。如果去车站的话，那边同行太多，和他们抢生意，不一定能抢得过。而现在这样，运气好的话，一天可以赚两天的钱。作者非常感慨，认为司机非常会做生意。不料司机说，这是他老婆教她的。
说到这里，或许有人在猜想，这。。。。怎么和以前那个了出租车MBA的故事很象？但事实并不是这样。
司机说他老婆不是开出租的，是擦鞋的，一天赚的钱是同行的四五倍。作者不信，于是司机一一道来：
他老婆每天起早，先到汽车客运站，有很多人等车，很无聊，这时候正好擦擦皮鞋。8、9点的时候，擦鞋的多了，她就到洗车店那里去，帮那些在洗车并且很无聊的人擦皮鞋，11点左右去车站附近的小饭店，那些在等上菜的人，也可能会擦皮鞋。下午1点多人少的时候，再去洗车店。再晚一点的时候，去写字楼门口，那些想去约会的小青年也会去擦擦皮鞋。
故事就这样结束了，虽然我认为事情可能是虚构的，但讲的道理也是有的：大多数人在做的事情，要么抢在他们前面，要么就干脆放弃。
顺便再讲个网上关于白领的新定义：今天发薪水，交了房租、水电费，买了油、米、煤气和泡面，摸摸口袋，感慨一下，这个月工资又白领了。
Tags: 出路, 思维, 出租车司机, 擦鞋
Misc | 评论:0
| 阅读:17746
