数据库的设计必须符合三个范式（极端要求常用高速时考虑单独设置记录表除外）。
用整形代替浮点型float，DECIMAL等，有的语言浮点计算是不精准的，如int存最小单位。金额用分， 重量用克等
- //价格分
- public function getPriceFen($priceFen)
- {
- return max(intval($priceFen), 1);
- }
数据库名称应该由概述项目内容的小写英文名词组成，以下划线分隔单词，避免跨平台时可能出现的大小写错误。数据表名称应该由物件对象名称的小写英文名词组成（尽可能对应系统中的业务类名称），以下划线分隔单词，避免跨平台时可能出现的大小写错误。
数据表的字段应避免使用varchar、 text等不定长的类型，时间信息的字段使用unixtiemstamp类型存储。查询数据时禁止使用*通配符避免占用资源加速处理速度，尽量避免使用临时表。查询数据连接多表时各资源应该使用全名称，即tableName.fieldName，而不是fieldName。SQL语句应尽可能符合ansi92标准，避免使用特定数据库对 SQL语言的扩充特性。开发结束后，必须针对SQL查询语句的条件语句部分（where）添加索引，须匹配多个条件的应该使用聚合索引。索引的组成应由左至右匹配条件语句的顺序。
严禁盲目添加索引，避免减慢数据插入的速度、增大占用空间及减慢查询速度。
每当数据库（表）发生结构性变化时须登记保存；日常须定时（不超过三个工作日）
备份数据库结构及其数据。
用filed='x'不要用filed="x"在MySQL中，使用单引号和双引号俩种表达方法是一样的，尽管使用单引号的表达方法符合ANSI-SQL/92标准。当修改了mysql的sql模式的时候（set @@global.sql_mode）的时候，选择不同sql模式，可能会出现单引号和双引号的区别。用的双引号，sql语句执行错误.可以看出，尽量还是使用单引号
数据库的字段设计有很多细节性的技巧，下面将过去在开发中体会到经验整理出来，做个备忘。
- tinyint 是-128到128 。当属性设置为unsigned的时候。最大值就是255了。现在知道为什么需要设置为unsigned属性了。原来是为了最大限度的使用给予的存储空 间。如果不设置。那么假如你的值都是正数的。那么-128这一百多个数字就相当于是浪费了。
- tinyint会自动设置为tinyint(3)。
- smallint 不设置unsigned的时候，也有3万多的样子。
- tinytext 就是255个字节。大概就是存储127个中文的样子 tinytext就相当于varchar类型。把它看成这样的该类型就容易理解了。
- int 类型phpmyadmin默认会设置int(10)。
- 概念纠正：原来一直以为这里的10表示位数。直到有次想保存1101061021496，结果在字段中的值都变成了：4294967295。 看MySQL手册上说：
(int后面括号的数字)显示宽度并不限制可以在列内保存的值的范围，也不限制超过列的指定宽度的值的显示。
- int的范围：-2147483648到2147483647。刚好是10个位，那么就是数十亿级别的数字。数据库设计经验：像订单的值非常大。不确定，如果达到10位数，还不如使用varchar类型。fangwei就没有使用int，而是varchar类型。
- 从上面也告诉我一个经验：如果保存在数据库的值都变成一样的。也就是无论我是1101061021496 还是1101061021569，结果都变成了固定的值，比如4294967295。那么可以考虑确认是否是数据库该字段的范围问题。这样的问题出现过好 几次了。就是没有掌握思路。导致浪费了不少时间。
- 将字段设置为not null 还出于另外一种考虑：mysql表的列中包含null的话，那么该列不会包含在所有中。也就是使用索引是无效的。所有，考虑今后会使用索引的字段，就要设置字段属性是not null。
- 如果你要保存NULL，手动去设置它，而不是把它设为默认值。
- 考虑到这个字段今后会作为查询关键字使用like的形式进行搜索。那么要将该字段定义成索引。这样使用like查询就会更快。
- 现在终于体会到到国外作者书籍上提到：设计数据库之前要问自己，之后会查询哪些数据。 考虑了这些，以后有什么查询需要。结构都能适应了。
关于设计大流量网站数据库，会员分表或者分库的设计考虑：
主键不要设为自增型。设置为自增型的后果就是：今后无法分离在不同的mysql数据库服务器上。比如id编号由于是自增的，所以两个数据库中可能会出现用户编号都是10005的情况。
但是，mysql主键会自动设置为自增型。可以用另外一个字段来作为标识符。而不是自增型id号。方法：新增一个字段作为行的标识符。具体设计：一个表做两个字段，一个是id作为主键，自增型，另外一个是uid，作为用户的标识。
程序判断上，是以uid作为判断用户的依据。而不是id主键作为判断依据(程序上的失误，改动比起数据库设计失误改动容易得多。因为你数据已经入库了。在修改起来就比较难了)。
