2023年7月27日发(作者：)

SQLServer数据库设计规范数据库设计规范1.简介数据库设计是指对⼀个给定的应⽤环境，构造最优的数据库模式，建⽴数据库及其他应⽤系统，使之能有效地存储数据，满⾜各种⽤户的需求。数据库设计过程中命名规范很是重要，命名规范合理的设计能够省去开发⼈员很多时间去区别数据库实体。最近也因为⼯作需要所以整理出了这个word⽂档，望⼤家指正。

2数据库设计数据库规划→需求分析→数据库设计→应⽤程序设计→实现→测试→运⾏于维护2.1数据库规划定义数据库应⽤系统的主要⽬标，定义系统特定任务，包括⼯作量的估计、使⽤资源、和需求经费，定义系统的范围以及边界。2.2需求分析2.1.1需求分析步骤与成果涉及⼈员：⽤户和分析⼈员任务：对现实世界要处理的对象进⾏详细的调查，收集基础数据及处理⽅法，在⽤户调查的基础上通过分析，逐步明确⽤户对系统的需求，包括信息的要求及处理的要求。⽅法与步骤：1.通过与⽤户的调查，对⽤户的信息需求进⾏收集。2.在收集数据的同时，设计⼈员要对其进⾏加⼯和整理，以数据字典和数据流图的形式描述出来，并以设计⼈员的⾓度向⽤户讲述信息，根据⽤户的反馈加以修改并确定（该过程是反复的过程）成果：数据流图，数据字典，各种说明性表格，统计输出表以及系统功能结构图。2.1.2数据流图基本元素与数据流图外部实体：存在于软件系统之外的⼈员或组织（正⽅形或⽴⽅体表⽰）。加⼯：数据处理，表⽰输⼊数据在此进⾏变换，产⽣输出数据（圆⾓巨型或圆形表⽰）。数据流：表⽰流动着的数据（箭头线表⽰）。数据存储：⽤来表⽰要存储的数据（开门矩形或两条平⾏横线表⽰）。

订单处理系统顶层流程图：0层数据流图：

2.3数据库设计2.3.1概念结构设计对事务加以抽象以E-R图的形式描述出来E-R图（实体联系图）：包括实体，联系，属性实体：现实中的事物例如，学⽣，⽼师联系：两个实体之间的关系，1:1、1：N、M:N三种关系属性：实体所具有的属性，例如 学⽣的学号、姓名、性别等例如：⼀个学⽣属于⼀个班级，⼀个班级拥有多名学⽣，E-R图如下

⽹上购物系统E-R图，该系统数据之间存在下列约束

1. ⼀个客户（编号唯⼀）可以拥有多个订单，每个订单仅属于⼀个客户。2. ⼀个订单（编号唯⼀）可以包含多个订购细⽬，每个订购细⽬只属于⼀个订单。3. ⼀个商品可以出现多个订购细⽬中，⼀个订购细⽬只包含多个商品。4. ⼀个商品类别可以包含多种商品，⼀种商品只属于⼀个商品类别。

图2.22.3.2逻辑结构设计2.3.2.1E-R图转换成关系模式 将E-R图转换成关系模式将每个实体转换成⼀个关系模式，实体的属性即关系模式的属性，实体的标识即关系模式的键。 根据规则合并E-R图中的1:1,1:N,M:N之间的联系1. 若实体的联系是(1:1)，则可以将两个实体转换成两个关系模式，任意⼀个关系模式的属性中加⼊另⼀个关系模式的主键（作为外键）和联系⾃⾝的属性2. 若实体间的联系是⼀对多（1：n），则将n端的实体类型转换成关系模式中加⼊1端实体类型的主键（作为外键）和联系类型的属性。3. 若实体间的联系是多对多（m:n），则将联系类型也转换成关系模式，其属性为2实体类型的主键（作为外键）加上联系类型⾃⾝的属性，⽽该关系模式的主键为2端实体主键的组合。4. 若关系模式是1：1：1的关系，转换原则同1：15. 若关系模式是1：1：n的联系，转换原则同1：n6. 若关系模式是1：n：m的联系，则可以将联系类型也转换成关系模式，其属性为m端和n端实体类型的主键（作为外键）加上联系类型⾃⾝的属性，⽽关系模式的主键为n和m端实体主键的组合7. 若关系模式是n:m:p的联系，转换规则同m:n根据E-R图实体之间的联系可以转换成以下关系模式：客户（客户编号，姓名，电话，E-mail）。关系的主键：客户编号；外键：⽆订单（订单编号，订购时间，客户编号）。关系的主键：订单编号；外键：客户编号订购细⽬（订购明细编号，订购数量，⽀付⾦额，订单编号）。关系主键：订购明细编号；外键：订单编号。出现（订购明细编号，商品编号，类型）。关系的主键：订购明细编号，商品编号；外键：订购明细编号，商品编号。商品：（商品编号，商品名称，单价，⽣产⽇期，商品类别号，商品类别名）。关系的主键：商品编号；外键：⽆在关系模式设计中可能会出现以下⼏个问题：数据冗余、数据修改不⼀致、数据插⼊异常、数据删除异常，所以提出范式的要求，⽬的就是最低限度地冗余，避免插⼊、删除、修改异常。2.3.2.2范式主属性：包含键的所有属性。 关系模式要求达到4NF （减少冗余，消除操作异常）第⼀范式（1NF）：若关系模式R的每⼀个分量是不可分的数据项，则关系模式属于第⼀范式。即每个属性都是不可拆分的.第⼆范式(2NF)：R属于1NF,且每⼀个⾮主属性完全依赖于键（没有部分依赖），则R属于2NF例如：选课关系(学号，课程号，成绩，学分)该关系的主键是（学号，课程号），但是课程号→学分，所以学分属性部分依赖于主键，即关系部满⾜第⼆范式，可以拆分为（学号，课程号，成绩），（课程号，学分）两个关系第三范式(3NF)：R属于2NF,且每个⾮主属性即不部分依赖于码，也不传递依赖于码例如：学⽣关系（学号，姓名，所属系，系地址）该关系的主键是:学号学号→所属系，所属系→学号，所属系→系地址；根据函数的依赖公理，系地址传递函数依赖于学号，即关系不满⾜第三范式，可以拆分关系为（学号，姓名，所属系），（所属系，系地址）如果不拆分会存在数据修改异常，⽐如该学⽣的换了系，修改了所属系，但是系地址没有修改，这样就造成了修改异常 BCNF：R属于3NF,且不存在主属性对码的部分和传递函数依赖例如：关系R（零件号，零件名，⼚商名），如果设定每种零件号只有⼀个零件名，但不同的的零件号可以有相同的零件名，每种零件可以有多个⼚商⽣产，但每家⼚商⽣产的零件应有不同的零件名。这样可以得到：零件号→零件名，（⼚商名，零件名）→零件号所以主属性包括（零件号，⼚商名，零件名），但是“零件名”传递依赖于码“⼚商名，零件名”，所以关系R不满⾜BCNF，当⼀个零件由多个⽣产⼚商⽣产时，由于零件号只有⼀个⽽零件名根据⼚商不同⽽⼜多个，零件名与零件号之间的联系将多次重复，带来数据冗余和操作异常现象可以将关系分解为（零件号，⼚商名），（零件号，零件名）4NF：关系模式R属于1NF,若对于R的每个⾮平凡多值依赖X→→Y且Y不包含于X时，X必含码，则R属于4NF5NF:对关系进⾏投影，消除关系中不是由候选码所蕴含的连接依赖对于上⾯的商品关系，由于关系的主键是商品编号，⽽商品类别号→商品类别名所以商品关系部满⾜第三范式，⾮主属性商品类别名传递依赖于商品编号，会存在数据冗余，数据修改异常问题。将商品关系分解为：商品（商品编号，商品名称，单价，⽣产⽇期，商品类别号）商品类别（商品类别号，商品类别名）2.3.3物理结构设计为⼀个给定的逻辑数据模型设计⼀个最合适应⽤要求的物理结构的过程 数据库的建⽴ 数据表的建⽴ 索引的建⽴ 视图的建⽴ 触发器的建⽴ 存储过程设计⽤户⾃定义函数设计 对关系模式的数据项加以约束，如检查约束、主键约束、参照完整性约束以保证数据正确性

2.4应⽤程序设计采⽤⾼级语⾔以结构化设计⽅法或⾯向对象⽅法进⾏设计2.5系统实现 3.优化策略3.1.查询优化策略1. 尽可能地减少多表查询或建⽴物化视图2. 只检索需要的列3. ⽤带IN的条件字句等级替换or字句4. 经常提交COMMIT，以尽早释放锁

3.2表设计1.如果频繁地访问涉及的是对两个相关的表进⾏连接操作，则考虑将其合并2.如果频繁地访问只是在表中的某⼀部分字段上进⾏，则考虑分解表，将该部分单独作为⼀个表3.对于很少更新的表，引⼊物化视图4. 当系统中有⼀些少量的，重复出现的值时，使⽤字典表来节约存储空间和优化查询。如地区、系统中⽤户类型的代号等。这类值不会在程序的运⾏期变化，但是需要存储在数据库中。 就地区⽽⾔，如果我们要查询某个地区的记录，则数据库需要通过字符串匹配的⽅式来查询；如果将地区改为⼀个地区的代号保存在表中，查询时通过地区的代号来查询，则查询的效率将⼤⼤提⾼。程序中宜⼤量的使⽤字典表来表⽰这类值。字典表中保存这类值的代号和实体的集合，以外键的⽅式关联到使⽤这类值的表中。然⽽，在编码阶段，程序员并不使⽤字典表，因为⾸先查询字典表中实体的代号，违背了提⾼查询效率的初衷。程序员在数据字典的帮助下，直接使⽤代号来代表实体，从⽽提⾼效率。虽然字典表在实际上并不使⽤，但是仍应该保留在数据库中（起码是在开发期内保留）。字典表作为另⼀种形式上的“数据字典⽂档”出现，以说明数据库中哪些表的哪些字段是使⽤了字典表的。为了提⾼数据库的数据完整性，在开发阶段可以保留完整的字典表和普通表的外键约束。但是在数据库的运⾏阶段，应该将普通表和字典表的外键删除，以提⾼运⾏效率，特别是某些表使⽤了很多字典表的情况。

案例：某数据库中有百万条⽤户信息，应⽤系统中常常需要按照地区要查询⽤户的信息。⽤户信息表以前是按照具体的地区名称来保存的，现在将具体的名称改为字典表中的地区代号，查询效率⼤⼤提⾼。

3.3索引1. 如果查询是瓶颈，则在关系上建⽴适当的索引；通常，作为查询条件的属性上建⽴索引可以提⾼查询效率。2. 如果更新是瓶颈，因为每次更新都会重建表上的索引，引起效率降低，则考虑删除某些索引。3. 选择适当索引，如果经常使⽤范围查询，则B树索引⽐散列索引更⾼效4. 将有利于⼤多数查询和更新的索引设为聚集性索引。

3.4提⾼IO效率1. 索引⽂件和数据⽂件分开存储，事务⽇志⽂件存储在⾼速设备上2. 经常修改数据⽂件和索引⽂件的页⾯⼤⼩3. 定期对数据进⾏排序4. 增加必要的索引项4.数据库命名规范4.1数据库对象对象数据库表视图索引前缀⽆⽆VIIX索引存储过程函数触发器⾃定义数据类型Default主键外键rule序列UNIQUEIXSPFNTRudDFpkFKruSquq数据库对象采⽤26个英⽂字母（区分⼤⼩写）和0－9这⼗个⾃然数，加上下划线_组成，共63个字符。不能出现其他字符（注释除外）。同⼀个数据库中这些对象名都是不能重复C CHECK_CONSTRAINTD DEFAULT_CONSTRAINTF FOREIGN_KEY_CONSTRAINTIT INTERNAL_TABLEP SQL_STORED_PROCEDUREPK PRIMARY_KEY_CONSTRAINTS SYSTEM_TABLESQ SERVICE_QUEUETR SQL_TRIGGERU USER_TABLEUQ UNIQUE_CONSTRAINTV VIEW4.2命名规范规定1.表名使⽤单数名例如：对存储客⼈信息的表（Customer）不使⽤Customers2.避免⽆谓的表格后缀1、 表是⽤来存储数据信息的,表是⾏的集合。那么如果表名已经能够很好地说明其包含的数据信息，就不需要再添加体现上⾯两点的后缀了。2、 GuestInfo(存储客户信息)应写成Guest，FlightList（存储航班信息的表）应写成Flight3.所有表⽰时间的字段，统⼀以 Date 来作为结尾（⽽不是有的使⽤Date,有的使⽤Time）以⼤家都熟悉的论坛来说，需要记录会员最后⼀次登录的时间，这时候⼀般⼈都会把这个字段命名为LoginTime 或者 LoginDate。这时候，已经产⽣了⼀个歧义;如果仅看表的字段名称，不去看表的内容，很容易将LoginTime理解成登录的次数，因为，Time还有⼀个很常⽤的意思，就是次数4.所有表⽰数⽬的字段，都应该以Count作为结尾5.所有代表链接的字段，均为Url结尾6.所有名称的字符范围为：A-Z, a-z, 0-9 和_(下划线)。不允许使⽤其他字符作为名称。7.采⽤英⽂单词或英⽂短语（包括缩写）作为名称，不能使⽤⽆意义的字符或汉语拼⾳。8.名称应该清晰明了，能够准确表达事物的含义，最好可读，遵循“见名知意”的原则。

4.3数据库命名规范数据库名称不需要简写，根据实际意义来命名。例如：ReportServer数据库名：ReportServer逻辑数据名：ReportServer；逻辑⽇志名：ReportServer_log物理数据名：；物理⽇志名：ReportServer_ATE DATABASE [ReportServer] ON PRIMARY( NAME = N'ReportServer', FILENAME = N'D:Microsoft SQL ' ,SIZE = 3328KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB ) LOG ON( NAME = N'ReportServer_log', FILENAME = N'D:Microsoft ERVERMSSQLuseDataReportServer_' , SIZE = 6400KB , MAXSIZE = 2048GB , FILEGROWTH =10%)GO注意：避免所有数据库的逻辑名称使⽤相同的名称。4.4表设计命名规范注意字段名不能使⽤保留关键字：如action,avg等1、不使⽤tab或tbl作为表前缀（本来就是⼀个表，为什么还要说明）2、表名以代表表内的内容的⼀个和多个名词组成，以下划线分隔，每个名词的第⼀个字母⼤写，例如：User、UserLogin，UserGroupRelation等3、使⽤表的内容分类作为表名的前缀：如，与⽤户信息相关的表使⽤前缀User，与内容相关的信息使⽤前缀Content。4、表的前缀以后，是表的具体内容的描述。如：⽤户登录信息的表名为：UserLogin，⽤户在论坛中的信息的表名为：UserBBSInfo5、⼀些作为多对多连接的表，可以使⽤两个表的前缀作为表名： 如：⽤户登录表UserLogin，⽤户分组表GroupInfo，这两个表建⽴多对多关系的表名为：UserGroupRelation4.4.1字段命名规范1. 字段名不要存在⽆⽤前缀，例如表‘WeiXinConfig’，既然我已经知道这张表是关于微信的表，⾥⾯的名称字段可以可以使⽤Name,不需要添加⽆⽤的前缀类似‘WeiXinName’，‘WeiXinGuanZhuMsg’，‘WeiXinUpImgMsg’等2. 字段使⽤实际英⽂翻译作为命名字段，见名知意,不要使⽤让⼈看了半天都不知道是啥意思的字段（类似：lev1,lev2…）4.5存储过程命名存储过程名=[SP_]+[表名]+[操作名字][操作名字]=[insert|delete|update|calculate|confirm]例如：SP_community_update4.5.1只允许应⽤程序通过存储过程访问数据库 只允许应⽤程序通过存储过程访问数据库，⽽不允许直接在代码中写SQL语句访问数据库。在数据库开发项⽬中，⼤量使⽤存储过程有很多的好处，⾸先看微软提供信息：

使⽤ SQL Server 中的存储过程⽽不使⽤存储在客户计算机本地的 Transact-SQL 程序的优势有：允许模块化程序设计：只需创建过程⼀次并将其存储在数据库中，以后即可在程序中调⽤该过程任意次。存储过程可由在数据库编程⽅⾯有专长的⼈员创建，并可独⽴于程序源代码⽽单独修改。允许更快执⾏：如果某操作需要⼤量 Transact-SQL 代码或需重复执⾏，存储过程将⽐ Transact-SQL 批代码的执⾏要快。将在创建存储过程时对其进⾏分如果某操作需要⼤量 Transact-SQL 代码或需重复执⾏，存储过程将⽐ Transact-SQL 批代码的执⾏要快。将在创建存储过程时对其进⾏分析和优化，并可在⾸次执⾏该过程后使⽤该过程的内存中版本。每次运⾏ Transact-SQL 语句时，都要从客户端重复发送，并且在 SQLServer 每次执⾏这些语句时，都要对其进⾏编译和优化。减少⽹络流量：⼀个需要数百⾏ Transact-SQL 代码的操作由⼀条执⾏过程代码的单独语句就可实现，⽽不需要在⽹络中发送数百⾏代码。可作为安全机制使⽤：即使对于没有直接执⾏存储过程中语句的权限的⽤户，也可授予他们执⾏该存储过程的权限。

除此以外，使⽤存储过程的好处还有：1、 在逻辑上，存储过程将应⽤程序层和数据库物理结构分离开来。存储过程形成了⼀个应⽤程序和数据库之间的接⼝。这样的接⼝抽象了复杂的数据库结构，符合极限编程中“基于接⼝编程”的思想。2、 将主要的业务逻辑封装在存储过程中，能够避免在应⽤程序层写⼤量的代码（在应⽤程序中通过字符串插⼊太长的SQL语句影响效率，⽽且维护困难）。有助于提⾼开发效率，并且直接在查询分析器中调试存储过程，能够更早的发现系统中的逻辑问题，从⽽提⾼代码的质量。3、 在⽹站⼀类的应⽤系统中，SQL注⼊式漏洞⼀直是难以完全杜绝的漏洞。如果只通过存储过程来访问数据库，能够⼤⼤减少这类安全性问题。（因此，就算是简单的只有⼀句的SQL语句，也应该写成存储过程。）4、 由于采⽤存储过程，应⽤程序的层⾯可以不关⼼具体的数据库结构，⽽只关⼼存储过程的接⼝调⽤。因此，在以下⼀些情况，存储过程的优势⾮常明显：·需求变更，表的结构必须要改变。使⽤存储过程，只要参数不变，我们就只需要修改相应的存储过程，⽽不需要修改应⽤程序的代码。这样的设计将减⼩需求变更对项⽬的影响。·为提⾼效率，使部分字段冗余：⼀些经常性访问的字段，我们可以在相关的表中进⾏冗余存储。这样既提⾼了效率，⼜通过存储过程屏蔽了冗余细节。·为提⾼效率，使⽤冗余表（拆分表）：⼀些⼤的表，为了提⾼查询效率，可能需要将记录分别保存到多个表中去。使⽤存储过程，有存储过程来决定从哪些拆分的表中获取或插⼊数据。这样提⾼了效率，⼜不必在应⽤程序层⾯关⼼具体的拆分规则。5、 使⽤存储过程，便于在项⽬后期或者运⾏中集中优化系统性能。在项⽬开发过程中，由于各种原因，往往⽆法编写⾼效的代码，这个问题常常在项⽬后期或者在运⾏期体现出来。通过存储过程来封装对数据库的访问，可以在项⽬集成以后，通过试运⾏观察系统的运⾏效率，从⽽很容易找出系统的瓶颈，并能够通过优化存储过程的代码来提⾼系统的运⾏效率。这样的优化，⽐在运⽤程序中优化更有效，更容易。

同时，过多的使⽤存储过程，也存在以下⼀些疑虑：问题⼀：存储过程编译后，将作为数据库的全局对象保存，太多的存储过程将占⽤⼤量的数据库服务器的内存。问题⼆：在存储过程中实现⼤量的逻辑，将使⼤量的运算在数据库服务器上完成，⽽不是在应⽤服务器上完成。当访问量很⼤的时候，会⼤⼤消耗数据库服务器的CPU占⽤率。在此还存在这个⼀个案例：有⼀个访问量巨⼤的⽹站，有多台WEB服务器构成⼀个负载均衡的服务器群集，但是只有⼀台中⼼的数据库服务器。当访问量持续增加的时候，接⼊更多的WEB服务器来满⾜⾼并发量的访问；但是数据库服务器却没办法⼀直增加。因此，就需要尽量在WEB服务器上完成业务逻辑，尽量避免消耗数据库服务器的资源。

对于这两个担⼼，我的想法是：问题⼀的解决：存储过程是经过编译后的SQL语句，在内存中是⼆进制的代码，并不会消耗太多内存。并且，存储过程⽐起直接使⽤SQL语句来说，效率⼤⼤提⾼。换个⾓度来说，这是⼀个“以空间换时间”的⽅案，多消耗⼀点内存来换取效率的提⾼，是值得的。问题⼆的解决：⾸先，在实现业务逻辑的问题上，在存储过程中实现⽐在应⽤程序中实现更容易；其次，从开发效率上，存储过程的开发⽐应⽤程序更简单（就完成相同逻辑⽽⾔）。在⾼访问量的系统中，应⽤服务器和数据库服务器的资源分配的问题，应该从成本的⾓度来开率：软件开发中的成本，⼈⼯⽀出的费⽤远远⾼于硬件⽀出的成本。我们可以很容易花钱购买更好的服务器，但是很难花钱让开发⼈员使程序有⼤幅度的提⾼。使⽤存储过程来封装业务逻辑，⾸先节省的是⼤量的开发时间和调试时间，并能够⼤⼤提⾼代码的质量。因此，从成本来说，应该使⽤存储过程。对于⼤访问量的情况，最简单的办法是投⼊更多的硬件成本：更快的硬盘，更⼤的内存和更多的CPU，还有更好的⽹卡…………等等。其次，在应⽤程序的层⾯，可以⼤量的使⽤静态⽂件缓存的办法来减轻数据库的压⼒。如：不经常变化的信息，可以从数据库服务器中读取，保存为应⽤服务器上的XML静态⽂件等。实在不⾏的话，应该在系统设计之初，考虑可能的访问量，将系统设计成分布式的。这样就能从根本上解决⼤访问量的问题。

4.5.2命名规范1、存储过程的前缀和表名的前缀类似：把⼀系列表看成⼀个对象，字段为对象的属性，存储过程则为访问对象的⽅法。如：添加⽤户的存储过程取名为：User_AddUser2、存储过程使⽤模块的前缀来命名。如，⽤户管理的存储过程使⽤前缀user_。3、存储过程的前缀之后，是动词+名词形式的存储过程名（也可以是动词短语）。4.5.3存储过程的参数命名1、参数名采⽤匈⽛利命名法，使⽤类型的前缀2、每个存储过程都有：@errno varchar(255)两个输出参数。应⽤程序中可以根据这两个参数得到存储过程执⾏的情况。(这两个参数使⽤默认值，可以忽略)errno为整型的错误信息代码，执⾏成功返回0。Errno的值的具体含义通过errmsg参数说明，或者通过代码中的注释或⽂档。Errmsg为错误信息的字符串描述，这个参数主要⽤于调试期作为说明，避免在应⽤程序中使⽤该值。同时，要注意英⽂版系统和中⽂版系统中，信息的语⾔选择对程序的影响。4.5.4存储过程返回的记录集1、存储过程的输出记录集：为程序的结构清晰，存储过程最好只返回⼀个记录集。但在某些为了提⾼性能的场合，还是可以输出多个记录集2、记录集中，每个输出的字段最后都指定字段的别名，以⾯真实的字段名信息流失到客户端，从⽽加⼤⿊客找到系统漏洞的可能。

4.5.5格式约定1、 所有SQL关键字⼤写2、 使⽤良好的变量命名规范3、 保持良好的结构，包括空⾏、缩进和空格等。4、 块状的语句，⼀定要写上BEGIN…END5、 在每个存储过程的开头加上详细的注释：包括存储过程名称、参数说明、功能说明、返回数据集说明、以及作者和版权声明。6、 每个存储过程内的代码前后必须加上SET NOCOUNT ON 和SET NOCOUNT OFF。7、 存储过程格式的⽰例如下：CREATE PROCEDURE SP_User_update( @Options VarChar(100), @strUserName varchar(20), @strPwd varchar(50), @errno int = 0 OUTPUT, @errmsg varchar(255)=NULL OUTPUT)

ASBEGIN IF @Options='UP1' BEGIN SET NOCOUNT ON /*以下是存储过程的代码*/ SET NOCOUNT OFF END

IF @Options='UP2' BEGIN SET NOCOUNT ON /*以下是存储过程的代码*/ SET NOCOUNT OFF ENDEND

4.6视图命名⼀个数据库中的视图名不能重复视图名=VI(前缀)+[表名]..[表名]+[描述]4.7主键命名⼀个数据库中的主键名不能重复主键名=PK_(前缀)+[表名]例如：pk_Community

4.8外键命名⼀个数据库中的外键名不能重复外键名=FK_(前缀)+[主表名]+[从表名]+[字段名]考虑这样⼀个关系，表Hotel，字段Id, Name, CityId。表City,字段Id,Name。因为⼀个城市可能有好多家酒店，所以是⼀个⼀对多的关系，City是主表(1⽅)，Hotel是从表(多⽅)。在Hotel表中，CityId是做为外键使⽤。在实现外键的时候我们可以这样写：ALTER TABLE HotelInfoADD CONSTRAINT FK_Hotel_City_Cityid FOREIGN KEY (CityID) REFERENCES City(ID)4.9触发器命名1. 前缀(tr),描述了数据库对象的类型。2. 基本部分，描述触发器所加的表。3. 后缀(_I、_U、_D)，显⽰了修改语句(Insert, Update及Delete)触发器名=TR_(前缀)+[表名]+[ _I、_U、_D]+[字段描述]例如：TR _Communtiy_u_name(对表community的字段name进⾏更新) 4.10 default约束 使⽤格式如：DF_[表名]_[列名]例如：DF _Community_Age

4.11CHECK 约束格式：CK_[表名]_[列名]例如：CK_Community_Number4.12UNIQUE约束格式：uq_[表名]_[列名]例如：uq_Community_Name

4.13字段命名规范1、字段不使⽤任何前缀（表名代表了⼀个名称空间，字段前⾯再加前缀显得罗嗦）2、字典名也避免采⽤过于普遍过于简单的名称：例如，⽤户表中，⽤户名的字段为UserName⽐Name更好。3、布尔型的字段，以⼀些助动词开头，更加直接⽣动：如，⽤户是否有留⾔HasMessage，⽤户是否通过检查IsChecked等。4、字段名为英⽂短语、形容词+名词或助动词+动词时态的形式表⽰，⼤⼩写混合，遵循“见名知意”的原则。4.14 SQL语句规范1、不允许写SELECT * FROM ……，必须指明需要读取的具体字段。2、不允许在应⽤程序代码中直接写SQL语句访问数据库。3、避免在⼀⾏内写太长的SQL语句，在SQL关键字的地⽅将SQL语句分成多⾏会更加清晰。 如：SELECT UserID,UserName,UserPwd FROM User_Login WHERE AreaID=20修改成：SELECT UserID,UserName,UserPwdFROM User_LoginWHERE AreaID=20更加直观4、在⼀些块形式的SQL语句中，就算只有⼀⾏代码，也要加上BEGIN…END块。 如：IF EXISTS(…) SET @nVar = 100应该写成：IF EXISTS(…)BEGIN SET @nVar = 100END5、SQL批处理语句的空⾏和缩进与⼀般的结构化程序语⾔⼀致，应该保持良好的代码格式。6、所有的SQL关键字⼤写 4.15游标使⽤约定1、 若⽆必要，不要使⽤游标2、 包含游标的存储过程，必须对性能进⾏认真测试。

4.16索引命名规范对于数据库的维护建索引是很平常的事情，但是如果没有⼀个规范化的命名，我们对于⼀个表的诸多索引可能需要花上⼀段时间的了解。1. 如果表中存在主键默认情况下，表的聚集性索引也就是主键列，主键的命名前⾯已经有提到过，索引名也跟主键名⼀样，（Pk_表名）2. 对于表上的⾮聚集索引，建议使⽤（IX0_表名，IX1_表名）….,这样下去,这样也很清晰地表达了索引，对于很多命名⽂章上提到的需要详细表达出具体的列，我个⼈觉得没有必要，⾸先聚集索引经常涉及多列，很难罗列出所有列；还有影响美观当你执⾏SELECT NAME FROM S 查询索引时，你根据NAME名很快就知道索引来⾃那张表，是否是⾮聚集索引，⽽不⽤根据OBJECTID列去跟对象表关联。4.17函数命名规范函数命名分两类：1.针对对象的函数，2.⽤作辅助功能操作的函数（不针对具体的数据库对象）1. 第⼀类命名：FN_+[User]+_+[对象名] 例如：FN_User_Student（对于Student进⾏操作函数）2. 第⼆类命名：FN_[具体函数解释] 例如：FN_Spit(对字段进⾏拆分函数)