一、表和字段命名
表和字段的命名以前面《命名原则》的约定为基本准则。
命名是程序规划的核心。古人相信只要知道一个人真正的名字就会获得凌驾于那个人之上的不可思议的力量。只要你给事物想到正确的名字，就会给你以及后来的人带来比代码更强的力量。
名字就是事物在它所处的生态环境中一个长久而深远的结果。总的来说，只有了解系统的程序员才能为系统取出最合适的名字。如果所有的命名都与其自然相适合，则关系清晰，含义可以推导得出，一般人的推想也能在意料之中。
就一般约定而言，类、函数和变量的名字应该总是能够描述让代码阅读者能够容易的知道这些代码的作用。形式越简单、越有规则，就越容易让人感知和理解。应该避免使用模棱两可，晦涩不标准的命名。
所有数据表名称，只要其名称是可数名词，则必须以复数方式命名，例如：cdb_members(用户表)、cdb_posts(帖子表)；存储多项内容的字段，或代表数量的字段，也应当以复数方式命名，例如：params(parameters，自定义Discuz!代码的参数个数)、views(查看次数)、replies(回复次数)。
当几个表间的字段有关连时，要注意表与表之间关联字段命名的统一，如cdb_threads表中的tid与cdb_posts表中的tid。
代表id自增量的字段，通常用以下几种形式：
1、最常用的核心id，或经常在URL中进行调用的，尽量用简写的形式，例如tid、pid、uid；
2、有功能性作用，URL中偶尔用到的id，使用全称的形式，例如pluginid；
没有功能性作用，只为管理和维护方便而设的id，可以使用全称的形式，也可只将其命名为id。
二、字段结构
允许NULL值的字段，数据库在进行比较操作时，会先判断其是否为NULL，非NULL时才进行值的必对。因此基于效率的考虑，所有字段均不能为空，即全部NOT NULL；
预计不会存储非负数的字段，例如各项id、发帖数等，必须设置为UNSIGNED类型。UNSIGNED类型比非UNSIGNED类型所能存储的正整数范围大一倍，因此能获得更大的数值存储空间；
存储开关、选项数据的字段，通常使用tinyint(1)非UNSIGNED类型，少数情况也可能使用enum()结果集的方式。tinyint作为开关字段时，通常1为打开；0为关闭；-1为特殊数据，例如N/A(不可用)；高于1的为特殊结果或开关二进制数组合(详见Discuz!中相关代码)；
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 |
转载请注明出处：https://www.onexin.net/rational-design-of-sql-database-structure/