标签：帕斯卡 div 推荐 固定 dash 生日 用户 link 命名
设计规范更多的是为了确保数据库设计的合理性、为了项目最终的协调稳定性，而命名规范则更多的是为了确保设计的正式和统一。公正的讲，数据库中表字段等等以什么样的方式命名、取具体什么名字，并不会直接影响到项目的稳定性。
制定规范的直接目的是约束设计行为，最终目的是确保设计的合理统一。规范虽然是有丰富项目经验的人制定的，但维护的却不是某个人的意志，而是项目的意志，因为遵守此规范对项目是好的有利的，此规范才有意义。所以规范是为了项目利益最大化而在团队人员中形成的一种约定（貌似约定的英文单词Convention本身就有规范的意思），所有参与设计的人员都要遵守此约定，所有参与开发的人员都会依此约定解读设计。我们约定，所有的主键统一命名为id，结果有设计人员违反约定将一个非主键字段命名为id，约定被打破，共识也就被打破，设计人员之间、开发人员与设计人员之间的沟通就出现了隔阂。
设计规范更多的是为了合理，命名规范更多的是为了统一，团队协作中，统一在某种程度上比局部设计开发的好坏更重要。违反了约定，局部设计开发的再好，反而可能影响到项目整体的稳定协调。
在“设计规范”中提到过一些命名规范，也详细讲述了表、字段的类型、注释等属性的设置，为什么要求主键统一命名为id、统一为char(32)类型，为什么要求浮点型数值统一为decimal类型？我们希望团队中所有人看到设计成果，一眼就可以明白这个字段是做什么的、代表的含义是什么，可以但不止于见名知意。再者，当前的开发模式，前后端代码及数据库文档、程序文档、接口文档等等大都是由工具生成，而其最底层的依据就是数据库，表、字段的命名注释同时会影响到工具生成的文档、代码中的类属性方法甚至是前台页面的命名注释，数据库设计命名的规范关系到整个项目的规范。
a．匈牙利命名法。由微软的一位匈牙利程序员Charles Simonyi提出，相对复杂，首字母小写，基本原则是：变量名＝属性＋类型＋对象描述，其中每一对象的名称都要求有明确含义，可以取对象名字全称或名字的一部分。匈牙利命名法主要在C或C++这种面向过程的程序语言中使用，如果用在Java、C#这种面向过程的语言中就很别扭。
b．Camel命名法。即骆驼式命名法，首字母小写，采用该命名法的名称看起来就像骆驼的驼峰一样高低起伏。Camel命名法有两种形式：
第一种是混合使用大小写字母，例如englishName、fartherCode。在Java中，属性名和方法名一般都采用这种命名方式，在C#中只有属性名采用这种命名方式，我们在前面也规定，SQLServer中字段的命名也采用这种方式。
第二种是单词之间加下划线，例如english_name、farther_code。我们在前面规定，Oracel和MySQL表、字段的命名都采用这种方式，不过我们要求Oracle全部使用大写字母，MySQL全部使用小写字母。再者，无论是在Java还是C#，甚至是在JavaScript中，所有的常量，都使用这种命名方式，但和Oracle表字段的命名方式一样要全部使用大写字母，比如前面的设计规范中介绍数据字典表时，字典类型、字典项的编码和文本信息需要即时获取，以往的习惯在程序中建立一个常量类，所有用到的字典数据在里面用常量标明，这时常量的命名方式即是如此。
c．Pascal命名法。即帕斯卡命名法，与Camel命名法类似，不过是首字母大写。在C#中，类名和方法名一般采用这种命名方式，在Java中类名一般采用这种方式。在前面也规定，SQLServer中数据库、表的命名也采用这种方式。
1、命名规范
采用26个英文字母(区分大小写)和0-9这十个自然数,加上下划线‘_‘组成,共63个字符。组合而成的变量名即可。
数据库及表名均不允许出现数字，字段名除非特殊情况不允许出现数字。
约定大于配置【Convention Over Configuration】
注意事项：
1) 以上命名都不得超过30个字符的系统限制.变量名的长度限制为29(不包括标识字符@).
2) 数据 对象、变量的命名都采用英文字符,单数形式，禁止使用中文命名.绝对不要在对象名的字符之间留空格.
3) 小心保留词,要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突
4) 保持字段名和类型的一致性,在命名字段并为其指定数据类型的时候一定要保证一致性.假如数据类型在一个表里是整数,那在另一个表里可就别变成字符型了.
5）多对多关系表，以Mapping结尾，如XXMapping
2、命名长度限制
3、单词缩写
建议当表名超过15个字符、字段名超过20个字符时就应该尝试用单词缩写重新命名，如果名称长度在此之内，原则上讲则尽可能不用缩写以使表述具体清晰，表、字段最终的名称长度要严格控制在30个字符以内。关于单词缩写规则如下：
a．如果可以在字典里找到一个词的缩写，就用这个做为缩写，比如：Monday=Mon、December=Dec，可在此网站下查找到一些英文单词的缩写：http://shortof.com/；
b．可以删除单词元音(词首字母除外)和每个单词的重复字母来缩写一个单词。比如：Current = Crnt、Address = Adr、Error = Err、Average = Avg；
c．对于主从表，如果主表名称没有缩写而从表的名称需要缩写，则从表名称从第二个单词开始缩写，第一个名词尽可能和主表保持一致。比如企业基本信息表名称为enterprise，则企业诉讼表enterprise_litigation可简写为enterprise_ltg，企业证书表enterprise_certificate可简写为enterprise_crt。最终的数据库表及由数据库表生成的程序在集成开发环境（IDE，Integrated Development Environment）中是按名称排列的，这样做是为了让相似功能的表、类文件排列在一起，方便开发者操作。
1、命名方式
2、关于表前缀
a．系统表（S_）：System，系统配置相关的基本信息表。系统用户表（S_USER）、系统角色表（S_ROLE）、系统菜单（S_LINK_MENU）、操作日志（S_OPERATION_LOG）、登录日志（S_LOGIN_LOG）、系统字典（S_DICTIONARY）、系统字典类型（S_DICTIONARY_TYPE）等。
b．字典表（D_）：Dictionary，非系统字典外的字典表。在“设计规范”——“相关注释”——“字典字段”中提到过字典表的定义，除了数据库中的通用字典表，还有一些常见表，比如地区表（D_REGION）、ICD编码（D_ICD）等，也是一种字典表，这里的D_前缀即加在这类字典表名前面。
c．中间表（R_）：Relationship，多对多关系中间表。具体命名方式建议为：R_主表名_从表名，在多对多关系中其实不分主从表，这里我们规定核心表为主表，另外一个为从表。比如用户角色关系中，用户表（S_USER）为主、角色（S_ROLE）表为从，那中间表就命名为R_USER_ROLE。当中间表名超长时，则根据实际情况缩写主从表名，建议优先缩写从表表名。
d．业务表（B_）：Business，核心业务涉及的基本信息表。这里的业务是非系统配置业务相关的，比如登录、注册、权限这些业务涉及的表都是和系统配置相关的，前缀应该是S_，而非B_。比如在线商城的项目中订单业务涉及的表即是核心业务表，会诊系统中会诊单业务涉及的表即是核心业务表，如果项目庞大，涉及业务较多，可以在B后面继续加单字母区分不同的业务，BA_、BB_、BC_……，没必要非得和某个英文对应，只是个代号，和项目组的人员说明即可。
3、关于字段命名
a．所有表中的主键统一命名为id，主键统一使用UUID，类型统一为char(32)。不建议使用复合主键，即便是在多对多关系的中间表中，还是建议用单独的字段做主键，复合字段加惟一约束。
b．所有的表字段中，除外键，其它字段名都无需刻意加前后缀，也不要在字段名前出现表名。这里的外键是广义上的外键，不仅包括从表引用主表主键的外键字段，还包括存放主表相应关键信息的扩展字段。
比如病人表（Patient），主键就是id而不是pateint_id，名称就是name而不是patient_name。但对于外键，比如其它表引用Patient表的主键那就是patient_id，对应Patient表的name字段那就是patient_name。如果一个表中有多个外键（字段）同时引用（对应）一张表的同一个字段，那再用其它标识。
c．对于字典字段，编码字段后面跟Code后缀，文本字段跟Text后缀，比如gender_code、gender_text。
d．本规范中要求所有表示日期时间的字段，都要有后缀，如果只精确到天则以date为后缀，如果要精确到时分秒那就用datetime作后缀。要求日期时间类型的字段，尽可能精确到时分秒，即便是像生日（birth_date）这种字段，一般只存储到年月日，但在选择字段类型时建议还是为datetime而非date。所以这里的后缀并不是和具体字段类型对应，而是根据实际业务情况，这个字段存储的数据多是精确到年月日还是时分秒，则后缀相应的为date或datetime。
注：日期时间尽量减少使用time做后缀，因为time还有一个很常用的意思，就是次数。比如登录日志表中有用户最后一次登录时间字段login_time，不去看表的内容，很容易将login_time理解成登录的次数。
e．本规范中建议是否注销、是否成功等类似的布尔型字段，名称前统一加is前缀，比如是否成功（is_success）、是否注销（is_active）、是否显示（is_display）等。
f.用尽量少的存储空间来存数一个字段的数据;例如：能使用int就不要使用varchar、char,能用varchar(16)就不要使用varchar(256);
IP地址最好使用int类型;
固定长度的类型最好使用char,例如：邮编;能使用tinyint就不要使用smallint,int;
最好给每个字段一个默认值,最好不能为null;
4、关于约束控制命名
唯一性和主键约束、外键约束、检查约束、空值约束、默认值约束
外键约束：以fk做前缀，后跟从表名称和主表名称：fk_从表名_主表名。
mysql
show Collation; -- 查看数据库的编码方式 show variables like ‘character%‘; -- 数据库编码 show variables like ‘collation%‘;
建议：MySQL数据库中将Character Set设置为utf8、将Collation设置为utf8_bin，并在数据库配置文件中设置lower_case_table_names=1，
第一范式(1NF)：字段值具有原子性,不能再分(所有关系型数据库系统都满足第一范式);
例如：姓名字段,其中姓和名是一个整体,如果区分姓和名那么必须设立两个独立字段;
第二范式(2NF)：一个表必须有主键,即每行数据都能被唯一的区分;
备注：必须先满足第一范式;
第三范式(3NF)：一个表中不能包涵其他相关表中非关键字段的信息,即数据表不能有沉余字段;
备注：必须先满足第二范式;
备注：往往我们在设计表中不能遵守第三范式,因为合理的沉余字段将会给我们减少join的查询;
例如：相册表中会添加图片的点击数字段,在相册图片表中也会添加图片的点击数字段;
标签：帕斯卡 div 推荐 固定 dash 生日 用户 link 命名
原文地址：http://www.cnblogs.com/bjlhx/p/7623695.html
