PHPCMS开发文档里看到PHP编码规范（4）

4.9.2. 错误报告级别

在软件开发和调试阶段，请使用error_reporting(E_ALL);作为默认的错误报告级别，此级别最为严格，能够报告程序中所有的错误、警告和提示信息，以帮助开发者检查和核对代码，避免大多数安全性问题和逻辑错误、拼写错误。error_reporting()可以在./include/common.inc.php的头几行进行设置。

在软件发布时，请使用error_reporting(E_ERROR | E_WARNING | E_PARSE);作为默认的错误报告级别，以利于用户使用并将无谓错误提示信息降至最低。

5. 数据库设计

5.1.字段

5.1.1. 表和字段命名

表和字段的命名以前面《4.4命名原则》的约定为基本准则。

所有数据表名称，只要其名称是可数名词，则必须以复数方式命名，例如：phpcms_member(用户表);存储多项内容的字段，或代表数量的字段，也应当以复数方式命名，例如：hits(查看次数)、items(内容数量)。

当几个表间的字段有关连时，要注意表与表之间关联字段命名的统一，如phpcms_article_1表中的articleid与phpcms_article_data_1表中的articleid。

代表id自增量的字段，通常用以下几种形式：

l 一般情况下，使用全称的形式，例如userid、articleid;

l 没有功能性作用，只为管理和维护方便而设的id，可以使用全称的形式，也可只将其命名为id。

篇幅所限，无法一一赘述，但所有与表、字段相关的命名，请务必大量参考phpcms现有字段的命名方式，以保证命名的系统性和统一性。

5.1.2. 字段结构

允许NULL值的字段，数据库在进行比较操作时，会先判断其是否为NULL，非NULL时才进行值的必对。因此基于效率的考虑，所有字段均不能为空，即全部NOT NULL;

预计不会存储非负数的字段，例如各项id、发帖数等，必须设置为UNSIGNED类型。UNSIGNED类型比非UNSIGNED类型所能存储的正整数范围大一倍，因此能获得更大的数值存储空间;

存储开关、选项数据的字段，通常使用tinyint(1)非UNSIGNED类型，少数情况也可能使用enum()结果集的方式。tinyint作为开关字段时，通常1为打开;0为关闭;-1为特殊数据，例如N/A(不可用);高于1的为特殊结果或开关二进制数组合(详见phpcms中相关代码);

MEMORY/HEAP类型的表中，要尤其注意规划节约使用存储空间，这将节约更多内存。例如cdb_sessions表中，就将IP地址的存储拆分为4个tinyint(3) UNSIGNED类型的字段，而没有采用char(15)的方式;

任何类型的数据表，字段空间应当本着足够用，不浪费的原则，数值类型的字段取值范围见下表：

字段类型 存储空间(b) UNSIGNED 取值范围

tinyint 1 否 -128~127

是 0~255

smallint 2 否 -32768~32767

是 0~65535

mediumint 3 否 -8388608~8388607

是 0~16777215

int 4 否 -2147483648~2147483647

是 0~4294967295

bigint 8 否 -9223372036854775808

~9223372036854775807

是 0

~18446744073709551615

5.2.SQL语句

所有SQL语句中，除了表名、字段名称以外，全部语句和函数均需大写，应当杜绝小写方式或大小写混杂的写法。例如select * from phpcms_member;是不符合规范的写法。

很长的SQL语句应当有适当的断行，依据JOIN、FROM、ORDER BY等关键字进行界定。

通常情况下，在对多表进行操作时，要根据不同表名称，对每个表指定一个1~2个字母的缩写，以利于语句简洁和可读性。

如下的语句范例，是符合规范的：

$result = $db->query(”SELECT m.*, i.*

FROM “.TABLE_MEMBER.” m, “.TABLE_MEMBERINFO.” i

WHERE m.userid=i.userid AND m.userid=’$_userid’);

5.3.性能与效率

5.3.1. 定长与变长表

包含任何varchar、text等变长字段的数据表，即为变长表，反之则为定长表。

l 对于变长表，由于记录大小不同，在其上进行许多删除和更改将会使表中的碎片更多。需要定期运行OPTIMIZE TABLE以保持性能。而定长表就没有这个问题;

l 如果表中有可变长的字段，将它们转换为定长字段能够改进性能，因为定长记录易于处理。但在试图这样做之前，应该考虑下列问题：

l 使用定长列涉及某种折衷。它们更快，但占用的空间更多。char(n) 类型列的每个值总要占用n 个字节(即使空串也是如此)，因为在表中存储时，值的长度不够将在右边补空格;

l 而varchar(n)类型的列所占空间较少，因为只给它们分配存储每个值所需要的空间，每个值再加一个字节用于记录其长度。因此，如果在char和varchar类型之间进行选择，需要对时间与空间作出折衷;

l 变长表到定长表的转换，不能只转换一个可变长字段，必须对它们全部进行转换。而且必须使用一个ALTER TABLE语句同时全部转换，否则转换将不起作用;

l 有时不能使用定长类型，即使想这样做也不行。例如对于比255字符更长的串，没有定长类型;

l 在设计表结构时如果能够使用定长数据类型尽量用定长的，因为定长表的查询、检索、更新速度都很快。必要时可以把部分关键的、承担频繁访问的表拆分，例如定长数据一个表，非定长数据一个表。例如phpcms的phpcms_member表等。因此规划数据结构时需要进行全局考虑;

进行表结构设计时，应当做到恰到好处，反复推敲，从而实现最优的数据存储体系。

5.3.2. 运算与检索

数值运算一般比字符串运算更快。例如比较运算，可在单一运算中对数进行比较。而串运算涉及几个逐字节的比较，如果串更长的话，这种比较还要多。

如果串列的值数目有限，应该利用普通整型或emum类型来获得数值运算的优越性。

更小的字段类型永远比更大的字段类型处理要快得多。对于字符串，其处理时间与串长度直接相关。一般情况下，较小的表处理更快。对于定长表，应该选择最小的类型，只要能存储所需范围的值即可。例如，如果mediumint够用，就不要选择bigint。对于可变长类型，也仍然能够节省空间。一个TEXT 类型的值用2 字节记录值的长度，而一个LONGTEXT 则用4字节记录其值的长度。如果存储的值长度永远不会超过64KB，使用TEXT 将使每个值节省2字节。

5.3.3. 结构优化与索引优化

索引能加快查询速度，而索引优化和查询优化是相辅相成的，既可以依据查询对索引进行优化，也可以依据现有索引对查询进行优化，这取决于修改查询或索引，哪个对现有产品架构和效率的影响最小。

索引优化与查询优化是多年经验积累的结晶，在此无法详述，但仍然给出几条最基本的准则。

首先，根据产品的实际运行和被访问情况，找出哪些SQL语句是最常被执行的。最常被执行和最常出现在程序中是完全不同的概念。最常被执行的SQL语句，又可被划分为对大表(数据条目多的)和对小表(数据条目少的)的操作。无论大表或小表，有可分为读(SELECT)多、写(UPDATE/INSERT)多或读写都多的操作。

对常被执行的SQL语句而言，对大表操作需要尤其注意：

l 写操作多的，通常可使用写入缓存的方法，先将需要写或需要更新的数据缓存至文件或其他表，定期对大表进行批量写操作。同时，应尽量使得常被读写的大表为定长类型，即便原本的结构中大表并非定长。大表定长化，可以通过改变数据存储结构和数据读取方式，将一个大表拆成一个读写多的定长表，和一个读多写少的变长表来实现;

l 读操作多的，需要依据SQL查询频率设置专门针对高频SQL语句的索引和联合索引。

而小表就相对简单，加入符合查询要求的特定索引，通常效果比较明显。同时，定长化小表也有益于效率和负载能力的提高。字段比较少的小定长表，甚至可以不需要索引。

其次，看SQL语句的条件和排序字段是否动态性很高(即根据不同功能开关或属性，SQL查询条件和排序字段的变化很大的情况)，动态性过高的SQL语句是无法通过索引进行优化的。惟一的办法只有将数据缓存起来，定期更新，适用于结果对实效性要求不高的场合。

MySQL索引，常用的有PRIMARY KEY、INDEX、UNIQUE几种，详情请查阅MySQL文档。通常，在单表数据值不重复的情况下，PRIMARY KEY和UNIQUE索引比INDEX更快，请酌情使用。

事实上，索引是将条件查询、排序的读操作资源消耗，分布到了写操作中，索引越多，耗费磁盘空间越大，写操作越慢。因此，索引决不能盲目添加。对字段索引与否，最根本的出发点，依次仍然是SQL语句执行的概率、表的大小和写操作的频繁程度。