<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
<channel>
<title><![CDATA[向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除]]></title> 
<link>http://jackxiang.com/index.php</link> 
<description><![CDATA[赢在IT，Playin' with IT,Focus on Killer Application,Marketing Meets Technology.]]></description> 
<language>zh-cn</language> 
<copyright><![CDATA[向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除]]></copyright>
<item>
<link>http://jackxiang.com/post//</link>
<title><![CDATA[[转]关于设计表时应该注意的问题]]></title> 
<author>jack &lt;xdy108@126.com&gt;</author>
<category><![CDATA[WEB2.0]]></category>
<pubDate>Thu, 26 Mar 2009 08:08:38 +0000</pubDate> 
<guid>http://jackxiang.com/post//</guid> 
<description>
<![CDATA[ 
	http://blog.chinaunix.net/u/29134/showart_1316574.html<br/>1、慎重选择表名。<br/><br/>有两种选择：<br/><br/>按照多数开发语言的命名规则。比如（myCustomer）。<br/><br/>按照多数开源思想命名规则。比如（my_customer）。<br/><br/>按照咱们中国人的思想。比如（我的客户）。<br/><br/>第一种有个缺点，很容易忘掉大写的字母。<br/><br/>第二种则比较好，每个WORD间用下划线连接，避免遗忘。<br/><br/>第三种建议不要用，虽然很好记。不觉得解析这个表的时候还需要编码转化吗？我个人理解，大家可以补充。<br/><br/>2.&nbsp;&nbsp;关于编码的设定。<br/><br/>A．&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GBK/GB2312.（适用于纯中文存储）。<br/><br/>B．&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UTF8.（适用于中英文混合存储）。<br/><br/>C．&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;LATIN1。（适用于纯英文存储）。<br/><br/>D.&nbsp;&nbsp;&nbsp;&nbsp; 其他的。<br/><br/>3. 关于表引擎的选择。<br/><br/>A.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MYISAM.（很多人说她的表级锁定会带来好多问题，其实只要设计好对应的表以及写好对应的SQL查询就没有那么大的问题。）<br/><br/>B.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;INNODB. （如果要用到事务，选择她不会错。至于多数人讲的MASTER/SLAVE结构上用INNODB在MASTER的选择是否正确，就要看你怎么用了。不能一味的疯狂使用INNODB。除非你想要确保非常高可用性，<br/><br/>）<br/><br/>C.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;CSV. （以前我写过文章，关于这个引擎。个人觉得最主要的是来存储少量数据以及从EXCEL到MYSQL的转换方面会很有用。当然只要涉及到规则数据的导入，她就可以办到。）<br/><br/>D.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;BLACKHOLE. （觉得最完美的用处在于MASETR/SLAVE上面，并且MASTER是一个临时的专门负责写的机器。不过缺点也很多，会与MYISAM或者INNODB或者其他的引擎有所冲突，这点自己要做个权衡）。<br/><br/>E.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MEMORY. （应该说是MYISAM的兄弟了。不过在读内存总比读磁盘的速度要快。不过要注意，它不支持动态数据类型）。<br/><br/>F.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FEDERATED. （典型的分布式引擎。我以前文章中有介绍。）<br/><br/>G.&nbsp;&nbsp;&nbsp;&nbsp;NDB。（网络版存储引擎。因为Replication 总是有延迟，所以如果系统容不得任何延迟，就用这个吧。）<br/>&nbsp;&nbsp; H.&nbsp;&nbsp;&nbsp;&nbsp;FOLCON。（6.0后用来代替INNODB的引擎。）<br/><br/><br/>I.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;其他旧的以及新开发的引擎具体介绍：http://dev.mysql.com/doc/refman/6.0/en/storage-engines.html）。<br/><br/>4. 关于属性数据类型的选择。<br/><br/>A.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;INT（一个字节的TINYINT，两个字节的SMALLINT，三个字节的MEDIUMINT，四个字节的INT，8个字节的BIGINT。记住：UNSIGNED不管你定义或者不定义，都不影响内部的存储字节大小）<br/><br/>B.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 少于10个字符用CHAR是在合适不过了。（不过要记住在MEMORY引擎里面会自动把VARCHAR转化为CHAR）<br/><br/>C.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 我一般用DECIMAL或者NUMERIC来代替FLOAT 或者DOUBLE。因为老板要求精确的数字。如果不要求精确的，那就用FLOAT吧。速度快，占空间小。（DECIMA、FLOAT(P)是动态存储。比如:DECIMAL(10,2)占用5个字节。FLOAT占4个字节，）<br/><br/>D.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BLOB，TEXT,VARCHAR（一般存放文章内容，特别是新闻网站。需要的字节数是所存储的字符长度+1。记住BLOB和VARCHAR是TEXT和CHAR的BINARY类型）<br/><br/>E.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ENUM（在一定范围内绝佳的代替VARCHAR和CHAR的工具，因为她只占一到两个字节。）<br/><br/>F.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 时间和日期类型（占3个字节的DATE，8个字节的DATETIME，4个字节的TIMESTAMP，3个字节的TIME，1个字节的YEAR。）。如果要存储比如‘1983’这样的年份，用YEAR明显比VARCHAR或者CHAR要节省空间。因为后者要占5个字节。<br/><br/>G.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;BOOLEAN（用来存储YES或者NO之类的值，占用一个字节。）<br/><br/>H.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;关于自增字段。目前我们的项目中涉及到好多ORDER BY RAND()操作。此类语句在数据库并发大的时候会造成CPU严重阻塞，持续产生数据库死锁！解决此类问题最好的办法就是利用自增字段，用程序随即生成数字序列，或者在数据库端随即生成数字序列。<br/><br/>I.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;关于ZEROFILL。非常好用的前置填补0的存储，而不是用用对应个数的空串来代替。在需要前置补零的操作中INT ZEROFILL可以用来代替CHAR或者VARCHR。<br/><br/>5.&nbsp;&nbsp;关于默认值。<br/><br/>A.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;在5.0之后，只要设定字段为NOT NULL，系统自动给出默认值。对应CHAR->’’,INT->0,BOOLEAN->0等等。<br/><br/>B.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 在5.0之前的版本，需要手动指定默认值，否则会出现一定的异常。到时候查都不好查了。<br/><br/>6.&nbsp;&nbsp;关于多数据库建立。<br/><br/>A.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;应该把对应的业务放在各自不同的数据库里，而不是所有业务放到一个库里面。<br/><br/>B.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 数据库的命名和表命名一样。<br/><br/>7.&nbsp;&nbsp;关于索引。<br/><br/>A.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;设计表初期尽量考虑到应该建立的索引。所有建立的索引一定要测试一下，看是否有必要，否则会翻倍的减少写数据的性能。<br/><br/>B.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 对于只有存储0或者1的列，尽量干掉索引，单独分出两个表。一个代替0，另外一个代替1。或者在一个字段里面用EMUM或者CHAR(0)或者CHAR(1)来代替。<br/><br/>&nbsp;&nbsp; PS： 最后一个要值得注意的，就是尽量所有的字段用NOT NULL。虽然MYSQL可以对NULL列进行索引，不过我不建议。
]]>
</description>
</item><item>
<link>http://jackxiang.com/post//#blogcomment</link>
<title><![CDATA[[评论] [转]关于设计表时应该注意的问题]]></title> 
<author> &lt;user@domain.com&gt;</author>
<category><![CDATA[评论]]></category>
<pubDate>Thu, 01 Jan 1970 00:00:00 +0000</pubDate> 
<guid>http://jackxiang.com/post//#blogcomment</guid> 
<description>
<![CDATA[ 
	
]]>
</description>
</item>
</channel>
</rss>