数据库设计和编码规范
数据库设计和编码规范
Version
目录
简介
读者对象
此文档说明书供开发部全体成员阅读。
目的
一个合理的数据库结构设计是保证系统性能的基础。一个好的规范让新手容易进入状态且少犯错，保持团队支持顺畅，系统长久使用后不至于紊乱，让管理者易于在众多对象中，获取所需或理清问题。
同时，定义标准程序也需要团队合作，讨论出大家愿意遵循的规范。随着时间演进，还需要逐步校订与修改规范，让团队运行更为顺畅。
数据库命名规范
团队开发与管理信息系统讲究默契，而制定服务器、数据库对象、变量等命名规则是建立默契的基本。
命名规则是让所有的数据库用户，如数据库管理员、程序设计人员和程序开发人员，可以直观地辨识对象用途。而命名规则大都约定俗成，可以依照公司文化、团队习惯修改并落实。
规范总体要求
1.避免使用系统产品本身的惯例，让用户混淆自定义对象和系统对象或关键词。
例如，存储过程不要以sp_或xp_开头，因为SQL SERVER的系统存储过程以
sp_开头，扩展存储过程以xp_开头。
2.不要使用空白符号、运算符号、中文字、关键词来命名对象。
3.名称不宜过于简略，要让对象的用途直观易懂，但也不宜过长，造成使用不方
便。
4.不用为数据表内字段名称加上数据类型的缩写。
5.名称中最好不要包括中划线。
6.禁止使用[拼音]+[英语]的方式来命名数据库对象或变量。
数据库对象命名规范
我们约定，数据库对象包括表、视图（查询）、存储过程（参数查询）、函数、约束。对象名字由前缀和实际名字组成，长度不超过30。避免中文和保留关键字，做到简洁又有意义。前缀就是要求每种对象有固定的开头字符串，而开头字符串宜短且字数统一。可以讨论一下对各种对象的命名规范，通过后严格按照要求实施。例如：
1.数据列参数
命名格式为@+[列名称]。
示例：@EmployeeID @employee_id
2.非数据列参数
在参数无法跟列名称进行关联时，使用能够反映该参数功能的英文单词或单词组合,采用Pascal样式命名。
示例：@WorkType @work_type
数据库设计规范
好的数据库架构设计对系统运行的性能起着很大的作用，所以要在开始时就要引起重视。为了保证数据库设计的高效必须安排时间对设计结果进行评审，这一环节必不可少。
选择有效的设计工具
数据库设计工具：Power Designer、ER Studio、Rose、Microsoft Visio。
项目开始前要确定使用哪种设计工具。(另有开发插件:RedGate系列(SQL Prompt))
选择的工具要便于讨论便入生成脚本导入数据库。
设计通过后要形成文档，并且这个结构设计文档要存档，签入VSS基线库中。
在进行数据库设计时，应随时进行数据字典的维护。(字段要求写说明)
表的设计
表设计在数据库设计中占据有十分重要的地位。表是实际存储数据的对象。除了要注重表结构设计，字段的设计之外还要注意表之间关系的设计。
遵守范式要求
通常，合理的规范化会最小化数据异常和减少数据的冗余。为了更新数据的正确与快速，在设计的初始阶段多采用三范式设计数据库表。
第一范式强调的是列的原子性，即列不能够再分成其他几列。
第二范式包含两层意思，一是表必须有一个主键；二是非主键列必须完全依赖于主键，且不能只依赖于主键的一部分。(尽量少使用复合主键)
第三范式需要确保数据表中的所有非主键列直接与主键列相关，而不能直接依赖于非主键列。
字段设计
1.尽量避免可为空的列。
虽然在个别情况下，允许空值可能是有用的，但是应尽量少用。这是因为需要对它们进行特殊处理，从而会增加数据操作的复杂性和增加CPU额外的逻辑判断。很多情况下可以考虑用默认值0或空字符串('')来代替NULL值。所以字段应该有NOT NULL的限制。
2.Unicode的选择。
nvarchar和nchar相应比varchar和char要占用更多的存储空间。设计的原则是：如果确保存储的内容只是纯英文和数字，用char/varchar。如果含有中文字符或其它多国语言，用nchar/nvarchar。
3.字段长度要精确，遵守“必须、够用”的原则。
精确的长度设计既能完整的描述数据，又可以节省存储空间。积小成大，当数据表中的数据有很多记录的时候，这种存储空间的优势就能体现得十分明显。存储空间越紧凑，分配的页面就越少，在同样大小的内存空间中就可以存储更多的页面，这样操
作数据的效率就会提高。例如能用char(10)的就不要用char(20),提高存储的利用率和系统性能，但同时也要兼顾扩展性和可移植性。
降低范式标准的一个重要原因是为了在检索数据时少连接表从而提供一个性能优势。或是预先汇总计算结果并存放起来，或是将相同字段内容一式多份地放在多个表中，这样数据的冗余会增加开发人员的工作量和业务判断。(最好是对有冗余的字段要另外用文档统一说明)
完全按照规范化设计的系统几乎是不可能的，除非系统特别的小，在规范化设计后，有计划地加入冗余是必要的。冗余可以是冗余数据库、冗余表或者冗余字段，不同粒
度的冗余可以起到不同的作用。冗余可以是为了编程方便而增加，也可以是为了性能的提高而增加。从性能角度来说，冗余数据库可以分散数据库压力，冗余表可以分散数据量大的表的并发压力，也可以加快特殊查询的速度，冗余字段可以有效减少数据库表的连接，提高效率。
数据库设计阶段，对必要的冗余处理可以事先安排设计，如果在代码实现阶段发现一些必要的冗余字段可以及早提出来考虑。
注意大类型的字段设计
如果设计过程中发现表中存在大类型(可存储2G)的字段时，要慎重考虑，因为这样的字段会造成单一数据页存放不了几条记录。而过多的页面也会在查询扫描时带来性能影响。
一般的做法是将XML、IMAGE、VARCHAR(MAX)、NVARCHAR(MAX)或TEXT 类型的字段切割到另外的数据表，而后与主数据表一对一连接。因为这些大型数据访问缓慢，修改时可能造成记录锁定较久。且在大多数的使用状态下，查询一般字段内容时可能根本用不到这些字段。这些列的存在会增加表的页面数，不分割出去容易会影响其它字段的修改和查询。
VARCHAR(MAX)、NVARCHAR(MAX)字段如果实际长度在8000以下，这个值将被作为常规的变长数据类型来对待，如果超过8000个字节，SQL Server将该值作为TEXT来存储处理。如果该表数据量比较大时，一定要考虑大字段分离设计原则。
少用TEXT和IMAGE，二进制字段的读写是比较慢的。
表关系和约束设计
正确处理表间关系。一对多、一对一、多对多等关系。主外键关系是保证数据完整性的一个重要机制。维护数据的正确性。尽量采用提供的约束，如主外键、检查、默认值、不可NULL等。尽可能不要通过程序或存储过程、触发器等机制来运行，毕竟SQL
SERVER约束是在内部以优化过的二进制程序代码来实现的，而其它方式效率当然不如直接设置的约束高。还有，能够确定具有唯一值的字段上尽量加上唯一性约束。一些约束在客户端判断的确是可以减少服务器的资源，但是不能完全保证数据的错误产生。而且用数据库使用域和参照完整性有时候还能帮助优化器减少查询执行时间。域和参照完整性帮助优化器分析有效的数据值而不需要物理访问数据，这减少了查询时间。
主键设计
所有的表必须设置主键。主键跟聚焦索引没有什么关系,但主键必须要有索引。主键的选择原则：
1.字段值唯一。
2.不可NULL。
3.字段大小尽量最小。
4.字段值不常变更。
5.不建议用复合主键。
主健值过大会影响外健数据表的大小。如果主键是聚集索引，由于所有非聚集索引都会存储聚集索引的键值，所以主键值过大，还将导致其他索引结构的效率不佳（页面数）。
主键关乎着数据的正确性与完整性。而聚焦索引是从数据的运行效率出发。虽然主键跟聚集索引是两回事，但基于主键的上述特性，所以主键往往适合作为表的聚集索引，这也是微软的默认做法。但一些没有意义的ID做聚集索引的意义不大，这时候需要在创建表的时候给主键指定为唯一的非聚集索引。
-- 主键约束(非聚集索引)：
ALTER TABLE[dbo].[TCustomer]ADD CONSTRAINT PK_TCustomer PRIMARY KEY NONCLUSTERED (ID);
选择GUID做为主键时在系统对接、移值和代码编写下都提供了很大的方便，但它是建立在牺牲性能的基础上。
在实际运用中，如果对于用36字符的GUID当作主键时，应当注意的问题如下：
1.GUID是无序的，所以不适合用来做聚集索引。否则会引起频繁的页面移动而产
生大量的碎片。
2.GUID类型的存储可以由char(36)改为uniqueidentifier类型（16个字节），
以节省存储空间。
3.对于有关联的表之间，考虑程序方便可用使用GUID做为主键，但对于独立的
表，还是以INT类型的字段做为主键来设计。所以设计阶段要分清哪些必须用GUID来做主键。
外键设计
外键的存在会在处理数据时带来麻烦，但实际上这点恰恰是它的好处。外键的存在就最高效的一致性维护方法。所以在表设计时要考虑主外键的设计。如果决定使用外键约束，那么所有人必须遵守严格执行。外键是最高效的一致性维护方法，数据库的一致性要求，依次可以用外键、CHECK约束、规则约束、触发器、客户端程序，一般认为，离数据越近的方法效率越高。
检查约束
约束除了主外键约束、唯一性约束和默认值约束外，还有一类叫检查约束。
检查约束是一个识别SQLServer表中每行可接受的列值的规则，检查约束帮助实施域的完整性，域完整性定义了数据库表中列的有效值，检查约束可以验证单列的域完整性，也可以验证多列的域完整性，在单个列上可以有多个检查约束，如果插入或更新的数据违反了检查约束，数据库引擎将暂时停止INSERT和UPDATE操作。
CREATE TABLE(
ID INT,
Code VARCHAR(20),
Sex CHAR(1)CONSTRAINT Text_Sex_CK CHECK (Sex ='F'OR Sex ='M'),
-- Sex列创建相应的约束，其值只能是'F'或'M'值。
Experience INT CONSTRAINT Text_Experience_CK CHECK (Experience >= 0)
-- Experience列创建相应的约束，其值必须>=0
);
索引的设计
索引是一把双刃剑，它通常可以加快数据检索数据的同时，往往又会带来额外的资源开销（在insert、update和delete使用时）。有时候这个开销代价甚至超过了查询优化带来的好处。所以，索引的创建是门艺术，要在工作中不断的积累经验和不断的总结。一般来说，建立索引要看数据使用的方式，也就是说那些访问数据的SQL语句经常使用，针对这些经常使用的SQL语句创建有效的索引还是值得的，但过多的索引又是对于OLTP（在线事务）数据库是不利的。
聚集索引和非聚集索引
每个表只能有一个聚集索引，因为目录只能按照一种方法进行排序。
聚集索引和数据是混为一体的，而非聚集索引是与数据独立分开的。
其实，我们的汉语字典的正文本身就是一个聚集索引。比如，我们要查“安”字，就会很自然地翻开字典的前几页，因为“安”的拼音是“an”，而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的，那么“安”字就自然地排在字典的前部。同样的，如果查“张”字，那您也会将您的字典翻到最后部分，因为“张”的拼音是“zhang”。也就是说，字典的正文部分本身就是一个目录，您不需要再去查其他目录来找到您需要找的内容。
我们把这种正文内容本身就是一种按照一定规则排列的目录称为“聚集索引”。
如果您认识某个字，您可以快速地从自典中查到这个字。但您也可能会遇到您不认识的字，不知道它的发音，这时候，您就不能按照刚才的方法找到您要查的字，而需要去根据“偏旁部首”查到您要找的字（非聚集索引查找），然后根据这个字后的页码直接翻到某页来找到您要找的字（书签查找）。但您结合“部首目录”和“检字表”而查到的字的排序并不是真正的正文的排序方法，比如您查“张”字，我们可以
看到在查部首之后的检字表中“张”的页码是672页，检字表中“张”的上面是“驰”字，但页码却是63页，“张”的下面是“弩”字，页面是390页。很显然，这些字并不是真正的分别位于“张”字的上下方，现在您看到的连续的“驰、张、弩”三字实际上就是他们在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我们可以通过这种方式来找到您所需要的字，但它需要两个过程，先找到目录中的结果，然后再翻到您所需要的页码。
通过以上例子，我们可以理解到什么是“聚集索引”和“非聚集索引”。
-- 聚集索引查找，没有书签查找开销
SELECT*FROM [dbo].[TOrder]
WHERE OrderID = 1
ORDER BY OrderID;
-- 非聚集索引查找
SELECT UserID,OrderID FROM [dbo].[TOrder]
WHERE UserID = 1
ORDER BY UserID;
-- 非聚集索引查找+书签查找
SELECT UserID,OrderID,OrderPrice FROM [dbo].[TOrder]
WHERE UserID = 1
ORDER BY UserID;
索引的初始创建原则
如果处在数据库项目的开始，而且不确定如何对索引建模，可以使用不加思考或默认索引模式作为开始。一旦能够根据实际事务信息重新评估数据库后，再调整索引。所以在系统的初始上线阶段一般只考虑创建最少的、最必要的索引。
1. 所有表要有聚集索引，如果没有合适的字段，那么暂时在主键上创建聚集索引。
2. 所有外键上创建索引。
3. 可预知的用来频繁查找的字段上创建索引。
4. 小表可以不需要特意去创建索引。有主键就好。
索引的注意事项
1.一个经常插入更新的表不要加太多索引，因为索引影响插入和更新的速度。
2.所有非聚集索引包含聚集索引键值，创建非聚集索引时不要再包含进来。
3.如果知道索引键的所有值都是唯一的，那么确保把索引定义成唯一索引。唯一索引
除了可以保证数据的正确性外还可能帮助优化器生成更高效的执行计划。因为在唯一索引中每行都是唯一的，一旦找到一行，SQL Server不必进一步查找其他匹配的行。
4.索引不只是带来查询优化，对于更新操作，索引有时候优化查询带来的好处会超过
索引维护的开销。所以索引有某些情况下会缩短整个数据更新的时间。因为有时候，表扫描带来的开销会远大于更新操作本身的开销。（先查找后更新）
5.尽可能地选择那些小数据类型的列来创建索引，大的索引键值增加了索引页面的数
量，从而增加了索引所需要的内存和磁盘活动数量。
6.经常有范围查询（between,> , <，> =, <=）或用来作条件返回很多列和order
by、group by发生的列，可考虑建立聚集索引；(分区字段是时间类型的话，适合聚集索引)
7.非聚集索引在需要从一个大表上读取少量的行时最有用。当匹配返回的记录数过多
时，需要用到的书签查找(键查找)的开销将会变得很大。所以像性别这样的字段不要创建非聚集索引。低选择性的列只能配合其它字段创建复合非聚集索引。
8.多个字段创建组合索引时要尽量使关键查询形成索引覆盖，其第一个列一定是使用
最频繁的列；但包含的列不能太多，不能有大类型的字段。
9.缺乏合适的索引也是造成阻塞、死锁的原因。
10.频繁更新的列不适合创建聚集索引。
11.主键就是聚集索引，极端错误的，是对聚集索引的一种浪费。虽然SQL SERVER
默认是在主键上建立聚集索引的。显而易见，聚集索引的优势是很明显的，而每个
表中只能有一个聚集索引的规则，这使得聚集索引变得更加珍贵。使用聚集索引的最大好处就是能够根据查询要求，迅速缩小查询范围，避免全表扫描。（尤其是分区表，适合时间做聚集索引）
索引的后期维护工作
索引创建后不就是完事了的，一定要定期观察索引在实际工作环境中的使用情况。及时阻止索引对系统带来的负面影响。总的来说应该考虑如下几点：
1.去掉使用率低的索引。
2.合理的改善索引，使索引更有效的被利用到。
3.创建缺失的必要的索引。
4.考虑索引碎片的问题。索引碎片率过大时，查询得不到优化。
由于表上有过度地插入、修改和删除操作，索引页被分成多块就形成了索引碎片，如果索引碎片严重，那么扫描索引的时间就会变长，甚至导致索引不可用，因此数据检索操作就慢下来了。如果碎片小于10%~20%，碎片不太可能会成为问题，如果索引碎片在20%~40%，碎片可能成为问题，但是可以通过索引重组来消除索引解决，大规模的碎片(当碎片大于40%)，可能要求索引重建。
-- 查看某个表的碎片情况(整理数据的碎片，是整理聚集索引的碎片）
-- 结果看LogicalFramentation字段
DBCC SHOWCONTIG('[dbo].[TLog]')WITH FAST,TABLERESULTS,ALL_INDEXES,NO_INFOMSGS;
总之，索引的后期跟踪是不断持续的过程。为了搭建高性能的系统环境，就必须定期有效的跟踪索引。
物理存储设计
除了重视逻辑对象的设计，还需要考虑数据库的物理设计。在并发要求很高、并发用户数很多的情况下，这一设计对数据库的性能起到十分关键的作用。
数据库物理文件一般不要存放在C盘，因为系统重装对C盘破坏最大。
日志文件另外存放
查询数据库的页，可以看到，由于页的ID不连续，所以数据文件内部的读写是随机的。而日志文件的读写是顺序的，所以两者放在同一个硬盘上，会造成硬盘驱动器一会随机，一会顺序，效率会比较低。将数据文件和日志分离存储在不同的物理硬盘上。这样的好处是确保数据的安全，避免单点失效。二是确保数据库的性能。同样备份文件也在不同的磁盘上。
存储空间的设计
正确评估和测算数据库的物理空间需求。因为数据库采用预先分配存储空间的方法。存储空间的分配操作是一个非常消耗资源的操作。所以设计人员需要评估数据空间的可能增长率，将数据库的空间增长方式设置为恰当好处，这样就可以在空间和效率之间取得均衡。
设计要考虑的内容有：
1.数据库文件和日志文件初始值的设计。
2.数据库文件和日志文件以多大的比例增长。（不要用默认的1M或10%）要设
置成按固定大小增长，这样就能避免一次增长太多或者太少所带来的不必要的
影响。建议对比较小的数据库，设置一次增长50 MB到100 MB。对大的数据库，设置一次增长200 MB到800 MB。
3.对于生产数据库，推荐的设置是开启数据库自动增长和不限制大小，以防数据
库空间用尽导致应用程序失败。
4.在系统一段时间稳定后，可以采取日志备份的机制使得数据库日志文件大小固
定下来，不再持续增长。事务日志备份可以截断日志，在检查点发生时会清空
日志，这样会在已有的空间内重新记录日志，而不用分配新的空间。
5.分配空间和压缩空间都很带来很大的资源开销，所以尽量避免数据库进行这两
个操作。比如对日志文件截断后不要使用收缩空间的操作，如果一定要收缩那么收缩到一个合适的值，这样避免日志文件重新分配空间。(不要收缩到最小空间，比如1M)
6.不要开启数据库的自动关闭和自动收缩选项。
T-SQL编码规范
在设计确定的情况下，编码的质量几乎决定了整个系统的质量。编码阶段首先是需要所有程序员有性能意识，也就是在实现功能同时有考虑性能的思想。
编写规范的SQL语句不但利于阅读，而且被数据库重复使用的几率也较大，执行效率相对较高，编写的好的SQL与编写的差的SQL在执行性能上可能会差几倍甚至几千几万倍，因此养成好的SQL编写规范对于提高项目质量及提高开发人员自身素质有着潜在的极大的影响。
书写基本规范
1.大小写规则。
为了最大限度实现SQL的共享，要求书写SQL语句时大小写要一致，（比如保留关键字、谓词和系统函数一律大写）这样做的好处有两点：一是为了阅读方便。
二是不统一的语句由于写法不完全相同，数据库会理解为4条不同的语句从而导致重复编译，降低了性能。系统对象（系统存储过程、视图、表，系统字段），按照系统定义的大小写执行（数据库里怎么定义就怎么引用）；数据库对象名称，按照实际定义的大小写执行（数据库里怎么定义就怎么引用）
2.养成注释的好习惯。
存储过程、函数、视图、触发器等对象不仅要求创建时加上必要的注释，而且在以后修改的过程中也应该有注释。注释最好以英文为主，尽可能做到简洁而描述清晰。另外表也可以加上注释说明。
3.有结束符。
每一个完整的T-SQL语句都要以分号结束。据说在以后的数据库版本里面会强制要求。现在的版本，在公用表达式的编写中，就有这个限制。
4.所有的赋值语句要求变量与运算符之间要有空格。如：v_count = v_count +
1;，并保持适当的对齐。
5.引用对象时带上架构名。这也是比较推荐的写法。默认的架构名为dbo。在创
建物化视图是就深有体会。
6.以内缩来标示IF、WHILE、BEGINEND、TRY CACHE等程序代码区域。
7.在SQL代码快中尽量使用BEGIN…END 语句块，提高代码可阅读性。
8.在多表连接时，尽量用表别名+字段的格式来返回列。
9.换行规则。BEGIN/END独占一行；FROM子句独占一行；WHERE子句独占
一行；GROUP BY 子句独占一行；ORDER BY 子句独占一行；单独的LEFT JOIN 和INNER JOIN 独占一行；如果一行写不完换行时，需要确保每行逻辑完整性。
使用可搜索参数（where使用原则）
建立索引后，并不是每个查询都会使用索引，在使用索引的情况下，索引的使用效率也会有很大的差别。只要我们在查询语句中没有强制指定索引，索引的选择和使用方法是SQLSERVER的优化器自动作的选择，而它选择的根据是查询语句的条件以及相关表的统计信息，这就要求我们在写SQL语句的时候尽量使得优化器可以使用索引。
为了使得优化器能高效使用索引，写语句的时候应该注意下面四点：
1.不要对索引字段进行运算，而要想办法做变换。
2.不要对索引字段进行格式转换。
3.不要对索引字段使用函数。
4.不要对索引字段进行多字段连接。
所以在where条件语句中有时候一些不规范的写法会造成索引失效。右边的写法要优于左边，因为右边可能会使得索引，而左列的写法是用不上索引的。（同样适用于ON 条件中）
NOT IN、LEFT JOIN、NOT EXISTS和IN、INNER JOIN、EXISTS的效率问题要具体情况具体分析。一般情况下推荐使用相关子查询（EXISTS）和连接的方式。
SQL Server从左到右处理表，这个在技术内幕上有。而where语句中最能快速筛选数据的列应该放在最前面，也就是最接近where子句的地方。但在SQL SERVER 2005后来的版本中，优化器会帮你自动优化的。
UNION操作依次执行所有的SELECT语句，将所有的结果集合并为一个结果集。将对结果集进行排序，并过滤掉重复的记录。可见联合查询的效率很低的，除非在必要的情况下才使用。如果允许结果集存在重复，或预知结果集根本不可能重复时一定要用UNION ALL来代替。
尽可能避免的地方
下面这些操作在使用前，可以重新思考下业务和检查一下逻辑，看是否可以避免。
数据库设计规范范本
数据库设计规范
1概述 1.1目的 软件研发数据库设计规范作为数据库设计的操作规范，详细描述了数据库设计过程及结果，用于指导系统设计人员正确理解和开展数据库设计。 1.2适用范围 1.3术语定义 DBMS：数据库管理系统，常见的商业DBMS有Oracle, SQL Server, DB2等。 数据库设计：数据库设计是在给定的应用场景下，构造适用的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 概念数据模型：概念数据模型以实体-关系(Entity-RelationShip,简称E-R)理论为基础，并对这一理论进行了扩充。它从用户的观点出发对信息进行建模，主要用于数据库概念级别的设计，独立于机器和各DBMS产品。能够用Sybase PowerDesigner工具来建立概念数据模型（CDM）。 逻辑数据模型：将概念数据模型转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。能够用Sybase PowerDesigner工具直接建立逻辑数据模型（LDM），或
者经过CDM转换得到。 物理数据模型：在逻辑数据模型基础上，根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。能够用Sybase PowerDesigner工具直接建立物理数据模型（PDM），或者经过CDM / LDM转换得到。 2数据库设计原则 按阶段实施并形成该阶段的成果物 一般符合3NF范式要求；兼顾规范与效率 使用公司规定的数据库设计软件工具 命名符合公司标准和项目标准 3数据库设计目标 规范性：一般符合3NF范式要求，减少冗余数据。 高效率：兼顾规范与效率，适当进行反范式化，满足应用系统的性能要求。 紧凑性：例如能用char(10)的就不要用char(20)，提高存储的利用率和系统性能，但同时也要兼顾扩展性和可移植性。 易用性：数据库设计清晰易用，用户和开发人员均能容易地理解。
软件工程-数据库设计规范与命名规则
数据库设计规范、技巧与命名规范 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。 数据库设计是指：对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据， 满足用户信息要求和处理要求。 数据库设计的各阶段： A、需求分析阶段：综合各个用户的应用需求(现实世界的需求)。 B、在概念设计阶段：形成独立于机器和各DBMS产品的概念模式(信息世界模型)，用E-R图来描述。 C、在逻辑设计阶段：将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。 然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。 D、在物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。 1. 需求分析阶段 需求收集和分析，结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。 需求分析的重点：调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法：调查组织机构情况、各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(Structured Analysis， 简称SA方法)从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典(Data Dictionary，简称DD)来描述。 2. 概念结构设计阶段 通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。 概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一 DBMS 支持的特定数据模型。 概念模型特点： (1) 具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。 (2) 应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。 概念模型设计的一种常用方法为IDEF1X方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术， 用于建立系统信息模型。 使用IDEF1X方法创建E-R模型的步骤如下所示:
数据库设计和编码规范
数据库设计和编码规范 Version
目录
简介 读者对象 此文档说明书供开发部全体成员阅读。 目的 一个合理的数据库结构设计是保证系统性能的基础。一个好的规范让新手容易进入状态且少犯错，保持团队支持顺畅，系统长久使用后不至于紊乱，让管理者易于在众多对象中，获取所需或理清问题。 同时，定义标准程序也需要团队合作，讨论出大家愿意遵循的规范。随着时间演进，还需要逐步校订与修改规范，让团队运行更为顺畅。 数据库命名规范 团队开发与管理信息系统讲究默契，而制定服务器、数据库对象、变量等命名规则是建立默契的基本。 命名规则是让所有的数据库用户，如数据库管理员、程序设计人员和程序开发人员，可以直观地辨识对象用途。而命名规则大都约定俗成，可以依照公司文化、团队习惯修改并落实。 规范总体要求 1.避免使用系统产品本身的惯例，让用户混淆自定义对象和系统对象或关键词。 例如，存储过程不要以sp_或xp_开头，因为SQL SERVER的系统存储过程以 sp_开头，扩展存储过程以xp_开头。 2.不要使用空白符号、运算符号、中文字、关键词来命名对象。 3.名称不宜过于简略，要让对象的用途直观易懂，但也不宜过长，造成使用不方 便。 4.不用为数据表内字段名称加上数据类型的缩写。 5.名称中最好不要包括中划线。
6.禁止使用[拼音]+[英语]的方式来命名数据库对象或变量。 数据库对象命名规范 我们约定，数据库对象包括表、视图（查询）、存储过程（参数查询）、函数、约束。对象名字由前缀和实际名字组成，长度不超过30。避免中文和保留关键字，做到简洁又有意义。前缀就是要求每种对象有固定的开头字符串，而开头字符串宜短且字数统一。可以讨论一下对各种对象的命名规范，通过后严格按照要求实施。例如：
数据库表及字段命名、设计规范
数据库表及字段命名、设计规范1、命名规范 1.1数据表的命名规范： 1）表的前缀应该用系统或模块的英文名的缩写（全部大写或首字母大写）。如果系统功能简单，没有划分为模块，则可以以系统英文名称的缩写作为前缀，否则以各模块的英文名称缩写作为前缀。例如：如果有一个模块叫做BBS(缩写为BBS)，那么你的数据库中的所有对象的名称都要加上这个前缀：BBS_ + 数据库对象名称，BBS_CustomerInfo标示论坛模块中的客户信息表。 2）表的名称必须易于理解，使用能表达表功能的英文单词或缩写英文单词，无论是完整英文单词还是缩写英文单词，单词首字母必须大写。如果当前表可用一个英文单词表示的，请用完整的英文单词来表示；例如：系统资料中的客户表的表名可命名为：SYS_Customer。如果当前表需用两个或两个以上的单词来表示时，尽量以完整形式书写，如太长可采用两个英文单词的缩写形式；例如：系统资料中的客户物料表可命名为：SYS_CustItem。 3）表的名称一般使用名词或者动宾短语 4）表名称不应该取得太长（一般不超过三个英文单词）。 5）在命名表时，用单数形式表示名称。例如，使用Employee，而不是Employees。 6）对于有主明细的表来说。明细表的名称为：主表的名称+ 字符Dts。例如：采购定单的名称为：PO_Order，则采购定单的明细表为：PO_OrderDts 对于有主明细的表来说，明细表必须包含两个字段：主表关键字、SN，SN字段的类型为int 型，目的为与主表关键字联合组成明细表的关键字，以及标示明细记录的先后顺序，如1,2,3……。 7）表必须填写描述信息
数据库表字段命名规范
数据库表字段命名规范 摘要：当前研发工作中经常出现因数据库表、数据库表字段格式不规则而影响开发进度的问题，在后续开发使用原来数据库表时，也会因为数据库表的可读性不够高，表字段规则不统一，造成数据查询，数据使用效率低的问题，所以有必要整理出一套合适的数据库表字段命名规范来解决优化这些问题。 本文是一篇包含了数据库命名、数据库表命名、数据库表字段命名及SQL语言编码的规范文档，针对研发中易产生的问题和常见错误做了一个整理和修改，为日后涉及到数据库相关的研发工作做好准备。 一、数据库命名规范 采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成，命名简洁明确，多个单词用下划线'_'分隔，一个项目一个数据库，多个项目慎用同一个数据库 二、数据库表命名规范 2.1数据表命名规范 （1）采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成，命名简洁明确，多个单词用下划线'_'分隔 （2）全部小写命名，禁止出现大写 （3）禁止使用数据库关键字，如：name，time ，datetime，password等（4）表名称不应该取得太长（一般不超过三个英文单词）
（5）表的名称一般使用名词或者动宾短语 （6）用单数形式表示名称，例如，使用employee，而不是employees 明细表的名称为：主表的名称+字符dtl（detail缩写） 例如：采购定单的名称为：po_order，则采购定单的明细表为：po_orderdtl （7）表必须填写描述信息（使用SQL语句建表时） 2.2命名规范 ①模块_+功能点示例：alllive_log alllive_category ②功能点示例：live message ③通用表示例：all_user 2.3待优化命名示例 ①冗余： 错误示例：yy_alllive_video_recomment yy_alllive_open_close_log 说明：去除项目名，简化表名长度，去”yy_” ②相同类别表命名存在差异，管理性差 错误示例：yy_all_live_category yy_alllive_comment_user 说明：去除项目名，统一命名规则，均为”yy_alllive_”开头即可 ③命名格式存在差异 错误示例：yy_showfriend yy_user_getpoints yy_live_program_get
数据库设计规范
数据库设计规范 V 1.0 2007-8-28
目录 1) 目的 (3) 2) 范围 (3) 3) 术语 (3) 4) 设计概要 (3) 5) 命名规范（逻辑对象） (4) 6) 数据库对象命名 (6) 7) 脚本注释 (8) 8) 数据库操作原则 (9) 9) 常用字段命名(参考) (9)
1) 目的 为了统一公司软件开发的设计过程中关于数据库设计时的命名规范和具体工作时的编程规范，便于交流和维护，特制定此规范。 2) 范围 本规范适用于开发组全体人员，作用于软件项目开发的数据库设计、维护阶段。 3) 术语 数据库对象：在数据库软件开发中，数据库服务器端涉及的对象包括物理结构和逻辑结构的对象。 物理结构对象：是指设备管理元素，包括数据文件和事务日志文件的名称、大小、目录规划、所在的服务器计算极名称、镜像等，应该有具体的配置规划。一般对数据库服务器物理设备的管理规程，在整个项目/产品的概要设计阶段予以规划。 逻辑结构对象：是指数据库对象的管理元素，包括数据库名称、表空间、表、字段/域、视图、索引、触发器、存储过程、函数、数据类型、数据库安全性相关的设计、数据库配置有关的设计以及数据库中其他特性处理相关的设计等。 4) 设计概要 ?设计环境 数据库：ORACLE 9i 、MS SQL SERVER 2000 等 操作系统：LINUX 7.1以上版本，显示图形操作界面; RedHat 9 以上版本 WINDOWS 2000 SERVER 以上 ?设计使用工具 使用PowerDesigner 做为数据库的设计工具，要求为主要字段做详尽说 明。对于SQL Server 尽量使用企业管理器对数据库进行设计，并且要求 对表，字段编写详细的说明（这些将作为扩展属性存入SQL Server中） 通过PowerDesigner 定制word格式报表，并导出word文档，作为数据 字典保存。（PowerDesigner v10 才具有定制导出word格式报表的功能）。
数据库命名规范(表、字段名)
数据库命名规范（表、字段名） 一. 实体和属性的命名 1常用单词已经进行了缩写，在命名过程当中，根据语义拼凑缩写即可。注意，由于ORCAL 数据库会将字段名称统一成大写或者小写中的一种，所以要求加上下划线 举例： 定义的缩写Sales: Sal 销售； Order: Ord 订单； Detail: Dtl 明细； 则销售订单名细表命名为：Sal_Ord_Dtl; 2.如果表或者是字段的名称仅有一个单词，那么建议不使用缩写，而是用完整的单词。举例： 定义的缩写Material Ma 物品； 物品表名为：Material, 而不是Ma. 但是字段物品编码则是：Ma_ID;而不是Material」。 3.所有的存储值列表的表前面加上前缀Z 目的是将这些值列表类排序在数据库最后。 4.所有的冗余类的命名（主要是累计表）前面加上前缀X 冗余类是为了提高数据库效率，非规范化数据库的时候加入的字段。或者表 5.关联类通过用下划线连接两个基本类之后，再加前缀R的方式命名，后面按照字母顺序罗列两个表名或者表名的缩写。 关联表用于保存多对多关系。 如果被关联的表名大于10个字母，必须将原来的表名的进行缩写。如果没有其他原因，建 议都使用缩写。 举例：表Object与自身存在多对多的关系，则保存多对多关系的表命名为：R_Object ； 表Depart和Employee;存在多对多的关系；则关联表命名为R_Dept_Emp 6.每一个表都将有一个自动ID作为主健，逻辑上的主健作为第一组候选主健来定义，如果是数据库自动生成的编码，统一命名为：ID;如果是自定义的逻辑上的编码则用缩写加“ID” 的方法命名。 举例：销售订单的编号字段命名：Sal_Ord」D ;如果还存在一个数据库生成的自动编号，则 命名为：ID。
软件设计编码规范
质量管理体系过程文件 软件设计编码过程 文件版本信息：
目录 1.目的 设计编码的目的在于设计和实现关于需求的解决方案。保证《需求规格说明书》中的各项要求在设计时都能够得到满足；对项目的编码实现进行质量控制，保证编码实现活动按计划顺利完成并与设计相一致。 2.范围 适用于公司的各类软件项目的系统设计编码过程。 3.术语 无 4.角色与职责
5.入口准则 ●《需求规格说明书》已通过评审。 6.输入 ●《需求规格说明书》 7.流程图 图1: 系统设计编码过程 8.主要活动 系统设计编码过程包括系统设计、系统实现。系统设计是指设计软件系统的体系结构、数据库、模块等，在需求和代码之间建立桥梁，一般分概要设计和详细设计两个阶段；系统实现是指开发人员按照系统设计去编码开发，并进行单元测试、代码走查；在设计编码过程中同时进行用户文档的编制。 8.1.概要设计 概要设计是分析各种设计方案和定义软件体系结构的过程。设计人员在充分了解需求的基础上，依据《需求规格说明书》选用适当的设计方法，分析与设计软件的结构、模块功能。通过系统分解，确定子系统的功能和子系统之间的关系，以及模块的功能和模块之间的关系，编写《概要设计说明书》。《概要设计说明书》必须经过技术评审。 8.1.1.解决方案选择 系统设计时可能会涉及到多种解决方案的选择，如： ●系统实现路线； ●采用的工具和技术； ●产品架构； ●设计模式； ●模块的制作、购买或重用等。 当出现多种候选方案，难以通过简单的方法判断出方案的优劣时，应按照《S_DAR00_决策分析和决定过程》进行决策。
8.1.2.概要设计 概要设计是建立整个软件的体系结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义等。概要设计的主要步骤有： ?选择设计方法； ?识别解决方案的主要组件：根据解决方案的技术架构和分析方法（面向对象、面向结 构），相应确定解决方案的组件模块； ?对候选技术和工具、组件进行评估，确定是进行开发、购买还是复用已有技术（工具 或者组件）。评估开发、购买或复用方案时需要考虑的事项包括：业务方面：可行性、产品成本、经验、投资回报、成熟度及其他因素；企业体系结构方面：解决方案必须 与当前状态和远景状态计划的约束相适应。包括与企业现有系统的集成等；技术方面：安全、组件模块交互标准、数据访问、数据存储、系统服务、开发工具、操作系统等。 ?识别解决方案主要组件的重要属性和关键关系：在前一任务的基础上，对解决方案主 要组件的重要属性和关键关系进行识别； ?进行数据库设计，建立数据库的逻辑模型和物理模型； ?进行用户界面设计，确定整个系统的界面框架以及界面风格； ?形成《概要设计说明书》。 8.1.3.概要设计评审 概要设计的结果应进行技术评审。技术评审由设计人员提出，由项目经理组织召开。技术评审会议应邀请需求分析师、公司的技术专家、开发人员、测试人员等参加。 关于技术评审会议的要求详见《评审过程》。 8.2.详细设计 详细设计可以和概要设计并行进行，但应考虑并行设计不会因概要设计而导致较大的详细设计返工。 8.2.1.详细设计 详细设计是从开发需求的角度描述解决方案的组件、服务和技术的过程。详细设计定义了解决方案的各个组成部分，以及这些组成部分的开发方法和交互方式。详细设计的步骤包括： ?选择用于开发解决方案的技术并完善设计模型：在概要设计的基础上，选择开发解决 方案采用的技术，并且完善对应的设计模型。
数据库设计规范
1概述 1.1目的 软件研发数据库设计规范作为数据库设计的操作规范，详细描述了数据库设计过程及结果，用于指导系统设计人员正确理解和开展数据库设计。 1.2适用范围 1.3术语定义 DBMS：数据库管理系统，常用的商业DBMS有Oracle, SQL Server, DB2等。 数据库设计：数据库设计是在给定的应用场景下，构造适用的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 概念数据模型：概念数据模型以实体-关系 (Entity-RelationShip,简称E-R)理论为基础，并对这一理论进行了扩充。它从用户的观点出发对信息进行建模，主要用于数据库概念级别的设计，独立于机器和各DBMS产品。可以用Sybase PowerDesigner工具来建立概念数据模型（CDM）。 逻辑数据模型：将概念数据模型转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。可
以用Sybase PowerDesigner工具直接建立逻辑数据模型（LDM），或者通过CDM转换得到。 物理数据模型：在逻辑数据模型基础上，根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。可以用Sybase PowerDesigner工具直接建立物理数据模型（PDM），或者通过CDM / LDM转换得到。 2数据库设计原则 按阶段实施并形成该阶段的成果物 一般符合3NF范式要求；兼顾规范与效率 使用公司规定的数据库设计软件工具 命名符合公司标准和项目标准 3数据库设计目标 规范性：一般符合3NF范式要求，减少冗余数据。 高效率：兼顾规范与效率，适当进行反范式化，满足应用系统的性能要求。 紧凑性：例如能用char(10)的就不要用char(20)，提高存储的利用率和系统性能，但同时也要兼顾扩展性和可移植性。 易用性：数据库设计清晰易用，用户和开发人员均能容
数据库命名规范(表、字段名)
数据库命名规范（表、字段名） 一．实体和属性的命名 1．常用单词已经进行了缩写，在命名过程当中，根据语义拼凑缩写即可。注意，由于ORCAL 数据库会将字段名称统一成大写或者小写中的一种，所以要求加上下划线 举例： 定义的缩写 Sales: Sal 销售； Order: Ord 订单； Detail: Dtl 明细； 则销售订单名细表命名为：Sal_Ord_Dtl; 2．如果表或者是字段的名称仅有一个单词，那么建议不使用缩写，而是用完整的单词。 一、【操作规范】 1. 如无备注，则表中的第一个id字段一定是主键且为自动增长； 2. 如无备注，则数值类型的字段请使用UNSIGNED属性； 3. 如无备注，排序字段order_id在程序中默认使用降序排列； 4. 如无备注，所有字段都设置NOT NULL，并设置默认值； 5. 如无备注，所有的布尔值字段，如is_hot、is_deleted，都必须设置一个默认值，并设为0； 6. 所有的数字类型字段，都必须设置一个默认值，并设为0； 7. 针对varchar类型字段的程序处理，请验证用户输入，不要超出其预设的长度； 8. 建表时将数据字典中的字段中文名和属性备注写入数据表的备注中(“PK、自动增长”不用写)； 9. 如无说明，建表时一律采用innodb引擎； 二、【常用表名约定】 0. 说明：表前缀用项目名称首字母缩写；所以表名都小写，单词之间用下划线分开，单
词都用单数形式 1. user –用户 2. category –分类 3. goods –商品、产品等一切可交易网站的物品都用此命名 4. good_gallery –物品的相册 5. good_cate –物品的分类，除了单独作为表名，其他地方分类单词一律用缩写cate 4. attr –属性 5. article –文章、新闻、帮助中心等以文章形式出现的，一般都用此命名 6. cart –购物车 7. feedback –用户反馈 8. order –订单 9. site_nav –包括页头和页尾导航 10. site_config –系统配置表 11. admin –后台用户【RBAC标准表】 12. role –后台用户角色【RBAC标准表】 13. access –后台操作权限，相当于action【RBAC标准表】 14. role_admin –后台用户对应的角色【RBAC标准表】 15. access_role –后台角色对应的权限【RBAC标准表】 16. 待续 三、【常用列名约定】 1. 表名_id –通常用作外键命名 2. cid –特殊的编号，带有元数据，方便关联查询，你可以把它理解成类别(层次)编号。举个例子，产品在分类时，往往需要将其归类到子分类下，相应的字段中也一般只记录子分类的id，这时若需要知道该产品属于哪个主分类，就需要通过子分类信息再查询到主分类信息，这是比较麻烦的，cid字段就是要解决这个问题。一般的站点几十个分类肯
设计用的国家标准
一．总图规划专业、建筑专业 序号标准规范编号标准规范名称0 _# V. [0 b# L) ~3 ~9 N 1 GB50028-2006 城镇燃气设计规范 2 GB50041-2008 锅炉房设计规范(08.8.1实施): I+ B {0 P W( w1 } 3 GB50049-9 4 小型火力发电厂设计规范( m3 o+ o, e$ z 4 GB50156-2002 汽车加油加气站设计与施工规范（2006年版） 5 GB50229-200 6 火力发电厂与变电所设计防火规范: X4 J$ e6 F 7 k& S 6 GB50351-2005 储罐区防火堤设计规范 7 DL5000-2000 火力发电厂设计技术规程* P8 V7 r# l6 h 8 DL/T5029-94 火力发电厂建筑装修设计标准8 Y) `" g; o) G0 n+ h! ? 9 DL/T5032-2005 火力发电厂总图运输设计技术规定' Q, I. A( d5 r n' | 10 DL/T5052-1996 火力发电厂辅助、附属及生活福利建筑物建筑面积标准3 l( Z1 a6 v; `( ^: c( p1 g3 |) c 11 DL/T5053-1996 火力发电厂劳动安全和工业卫生设计规程 12 DL/T5094-1999 火力发电厂建筑设计规程) C! z$ A( \0 z: T7 x/ t ) ?) h4 _- U2 e. \$ k$ M) G 7 k) n, p1 c3 H) S2 }: T3 y 2 Y! l u- ~& E) J" T1 _: b 二．结构专业 序号标准规范编号标准规范名称 23 GB50041-2008 锅炉房设计规范(08.8.1实施) 24 GB50049-94 小型火力发电厂设计规范 25 GB50051-2002 烟囱设计规范! F8 u3 l( d ^ 26 GB50229-2006 火力发电厂与变电所设计防火规范 27 GB50351-2005 储罐区防火堤设计规范1 p0 B' o' A" B 29 DL5000-2000 火力发电厂设计技术规程 30 DL5022-93 火力发电厂土建结构设计技术规定 31 DL/T5024-2005 电力工程地基处理技术规定 32 DL/T5030-1996 薄壁离心钢管混凝土结构技术规程1 R8 J- P8 _& B$ R6 g 33 DL/T5045-2006 火力发电厂灰渣筑坝设计技术规定$ P6 U8 z1 p& ]2 f/ h0 J 34 DL/T5073-2000 水工建筑物抗震设计规范; t" d, c# k) E! F, [6 u" b 35 DL/T5085-1999 钢—混凝土组合结构设计规程; M0 X+ O% }, S9 T1 `( n7 b 36 DL/T5095-2007 火力发电厂主厂房载荷设计技术规程+ p5 k1 Z H/ r1 i4 u 37 DL/T5101-1999 火力发电厂振冲法地基处理技术规范8 c. [. C% g0 K 38 DL/T5188-2004 火力发电厂辅助机器基础隔振设计规程( S3 U8 }+ | e8 q 39 DL/T693-1999 烟囱混凝土耐酸防腐蚀涂料 40 DLGJ158-2001 火力发电厂钢制平台扶梯设计技术规定' }5 O; l* W8 @- @" _0 J/ A7 L 三．电气专业 序号标准规范编号标准规范名称 31 GB50041-2008 锅炉房设计规范(08.8.1实施) 32 GB50049-94 小型火力发电厂设计规范 33 DL5000-2000 火力发电厂设计技术规程) t9 _* l9 z. C: ^/ P6 B9 z. F9 J
Greenplum数据库设计开发规范
G r e e n p l u m数据库设 计开发规范 集团企业公司编码：（LL3698-KKI1269-TM2483-LUI12689-ITT289-
目录
第一章前言 1.1文档目的 随着Greenplum数据库的正式上线使用。为了保证Greenplum 数据仓库系统平台的平稳运行，保证系统的可靠性、稳定性、可维护性和高性能。特制定本开发规范，以规范基于Greenplum数据库平台的相关应用开发，提高开发质量。 1.2预期读者 Greenplum数据仓库平台应用的设计与开发人员； Greenplum 数据仓库平台的系统管理人员和数据库管理员； Greenplum 数据仓库平台的运行维护人员； 1.3参考资料 参考Greenplum4.3.x版本官方指引： 《GPDB43AdminGuide.pdf》 《GPDB43RefGuide.pdf》 《GPDB43UtilityGuide.pdf》
第二章设计规范 2.1数据库对象数量 数据库对象类型包括数据表、视图、函数、序列、索引等等，在Greenplum数据库中，系统元数据同时保存在Master 服务器和Segment 服务器上，过多的数据库对象会造成系统元数据的膨胀，而过多的系统元数据造成系统运行逐步变慢；同时，类似数据库的备份、恢复、扩容等较大型的操作都导致效率变慢。因此，依据GreenplumDB产品的最佳时间，单个数据库的对象数量，应控制在10万以内。 GP数据库的对象包括：表、视图、索引、分区子表、外部表等。 如果数据表的数量太多，建议按应用域进行分库，尽量将单个数据库的表数量控制在10万以内，可以在一个集群中创建多个数据库。 【备注】：在Greenplum数据库中，一张分区表，在数据库中存储为一张父表、每张分区子表都是一张独立的库表；例如：一张按月进行分区的存储一年数据的表，如果含默认分区，共14张表。 2.2表创建规范 为了避免数据库表数量太多，避免单个数据表的数据量过大，给系统的运行和使用带来困难，在Greenplum数据库中需遵循如下的表创建规范： 1、GP系统表中保存的表名称都是以小写保存。通常SQL语句中表名对大小写不敏感。但不允许在建表语句中使用双引号（“”）包括表
数据库命名设计规范
数据库命名、设计规范 一、数据库表及字段 1．数据库表的命名规范： 表的前缀应该用系统或模块的英文名的缩写（全部大写）。如果系统功能简单，没有划分为模块，则可以以系统英文名称的缩写作为前缀，否则以各模块的英文名称缩写作为前缀。例如：如果有一个模块叫做BBS(缩写为BBS),那么你的数据库中的所有对象的名称都要加上这个前缀：BBS_ + 数据库对象名称，BBS_CustomerInfo标示论坛模块中的客户信息表。 表的名称必须是易于理解，能表达表的功能的英文单词或缩写英文单词，无论是完整英文单词还是缩写英文单词，单词首字母必须大写。如果当前表可用一个英文单词表示的，请用完整的英文单词来表示；例如：系统资料中的客户表的表名可命名为：SYS_Customer。如果当前表需用两个或两个以上的单词来表示时，尽量以完整形式书写，如太长可采用两个英文单词的缩写形式；例如：系统资料中的客户物料表可命名为：SYS_CustItem。 表名称不应该取得太长（一般不超过三个英文单词）。表名长度不能超过30个字符，表名中含有单词全部采用单数形式，单词首字母必须大写。在命名表时，用单数形式表示名称。例如，使用 Employee，而不是 Employees。对于有主明细的表来说。明细表的名称为：主表的名称 + 字符Dts。例如：采购定单的名称为：PO_Order，则采购定单的明细表为：PO_OrderDts;对于有主明细的表来说，明细表必须包含两个字段：主表关键字、SN，SN字段的类型为int型，目的为与主表关键字联合组成明细表的关键字，以及标示明细记录的先后顺序，如1,2,3……。表必须填写描述信息，后台表名尽量与前台表名相同，后台独有的表应以_b作为后缀。如r_gggd_b。 数据库表的命名采用如下规则： 1)表名用模块名_开头，表名长度不能超过30个字符，表名中含有单词全部采用单数形式，单词首字母必须大写。 2)多个单词间用下划线（_）进行连接。若库中有多个系统，表名采用系统名称+单词或多个单词，系统名是开发系统的缩写，如VNET。
数据库设计规范 编码规范
数据库编码规范 目的1 为了统一公司软件开发的设计过程中关于数据库设计时的命名规范和具体工作时的编程规范，便于交流和维护，特制定此规范。 2 范围 本规范适用于全体开发人员，作用于软件项目开发的数据库设计、维护阶段。 术语3 数据库对象：在数据库软件开发中，数据库服务器端涉及的对象包括物理结构和逻? 辑结构的对象。 物理结构对象：是指设备管理元素，包括数据文件和事务日志文件的名称、大小、? 目录规划、所在的服务器计算极名称、镜像等，应该有具体的配置规划。一般对数据库服产品的概要设计阶段予以规划。务器物理设备的管理规程，在整个项目/ 逻辑结构对象：是指数据库对象的管理元素，包括数据库名称、表空间、表、字段? 域、视图、索引、触发器、存储过程、函数、数据类型、数据库安全性相关的设计、数据/ 库配置有关的设计以及数据库中其他特性处理相关的设计等。 4 设计概要 4.1 设计环境R2 ORACLE 11G a) 数据库ORACLE 11G R2 操作系统 LINUX 6以上版本，显示图形操作界面 b) MS SQL SERVER 2005 数据库企业版 SQL SERVER 2005 以上补丁和安全补丁打sp3 操作系统 WINDOWS 2008 SERVER 4.2 设计使用工具做为数据库的设计工具，要求为主要字段做详尽说明。对于PowerDesigner a) 使用尽量使用企业管理器对数据库进行设计，并且要求对表，字段编写详细的说SQL Server
明（这些将作为扩展属性存入SQL Server中） 文档，作为数据字典保存，PowerDesigner b) 通过定制wordword格式报表，并导出SQL Server PowerDesigner v10 格式。（才具有定制导出word格式报表的功能）。对于一旦在企业管理器进行数据库设计时加入扩展属性，就可以通过编写简单的工具将数据字典导出。 编写数据库建数据库、建数据库对象、初始化数据脚本文件c) 设计原则4.3 采用多数据文件a) 500MB 2GB,windowb) 禁止使用过大的数据文件，系统不超过unix系统不大于数据库中必须将索引建立在索引表空间里。c) oracle 基本信息表在建立时就分配足够的存储空间，禁止其自动扩展功能d) blob(或大文本列)和大文本字列、e) blob列要独立出一张表，此表只有id 或saf) 为每一个数据库创建独立的管理员用户，使用该用户进行设计，尽量不要使用者系统管理员身份进行数据库设计。 4.4 设计的更新 a) 在设计阶段，由数据库管理员或指定的项目组其一成员进行维护。 b) 运行阶段，由数据库管理员进行维护。 c) 如对表结构进行修改，应先在数据字典文档进行修改，最后在数据库中进行修改。如果修改的是数据库字典表，必须由数据库管理员进行。 直接连代码，如果使用PowerDesigner，禁止由PowerDesignerd) 编写更新的SQL数据库进行数据库操作（如果是更改表或者字段的说明性文字可以通过数据库管理器图形界面进行修改） e) 修改数据库要通过SQL，禁止其它方式对数据进行修改 要添加说明后保存备查修改数据库的SQLf) 命名总体原则5 设定的前缀一律用小写字母? ? 标识名称命名全部小写 整个命名的全长不得超过30个字母? ，不能使用中文和其他字符，有特别情况允许使用末尾数‘_'? 全部使用字母和下划线t_Finace1, t_Finace2... 字编号。例如： ? 命名名称来自于业务，全部采用英文单词 英文单词过长可以采用通用的缩写，尽量表达出业务的含义? 如需要两个以上的英文单词做标识名称，单词之间要用下划线‘_'? 连接 ? 名称全是由名词组成的，名词由大范围到小范围排序取名
数据库设计规范
- 茶马古道电子商务有限公司 数据库设计规范 V 1.0 版权所有
文档信息 作者： 创建日期（yyyy-mm-dd）: 审核者: 审核日期（yyyy-mm-dd）: 最后修订者： 最后修订日期（yyyy-mm-dd）: 文档类型： 文档修订历史 版本号修订日期修订者修订内容1.0.0 2011.9.20 金洋初始化
数据库约定 对应于XXXX MYSQL数据库环境的数据库类型定义如下表：1 Development Database 开发环境使用 开发环境数据库 2 Quality Assurance Database 质保环境使用 质保环境数据库 3 Production Database 生产环境使用 生产环境数据库 4 Training Database 培训环境使用 培训环境数据库 5 SIT Database 集成测试环境使用集成测试环境数据库 数据库字符集选择UTF8字符集 (建库时确定) 1. 数据库元素命名规范 长度约定：字段名，表名，视图名称等长度不能超过25个字符1.1. 表命名规范 数据类型数据类型（英文）前缀 主数据Master Data Table TM 业务事务处理数据Transaction Data Table TT 关系表Relationship Table TR 代码列表Code List Table TC 接口表Interface Table TI 系统管理表System administration Table TS 日志表Log Table TL 历史表History Table TH 中间临时表Temparory table TE 汇总表Aggregation Table TA 归档表Archivie Table TZ
数据库表及字段命名、设计规范
数据库表及字段命名、设计规范 1、命名规范 1.1数据表的命名规范： 1）表的前缀应该用系统或模块的英文名的缩写（全部大写或首字母大写）。如果系统功能简单，没有划分为模块，则可以以系统英文名称的缩写作为前缀，否则以各模块的英文名称缩写作为前缀。例如：如果有一个模块叫做BBS(缩写为BBS)，那么你的数据库中的所有对象的名称都要加上这个前缀：BBS_ + 数据库对象名称，BBS_CustomerInfo标示论坛模块中的客户信息表。 2）表的名称必须易于理解，使用能表达表功能的英文单词或缩写英文单词，无论是完整英文单词还是缩写英文单词，单词首字母必须大写。如果当前表可用一个英文单词表示的，请用完整的英文单词来表示；例如：系统资料中的客户表的表名可命名为：SYS_Customer。如果当前表需用两个或两个以上的单词来表示时，尽量以完整形式书写，如太长可采用两个英文单词的缩写形式；例如：系统资料中的客户物料表可命名为：SYS_CustItem。 3）表的名称一般使用名词或者动宾短语 4）表名称不应该取得太长（一般不超过三个英文单词）。 5）在命名表时，用单数形式表示名称。例如，使用 Employee，而不是 Employees。 6）对于有主明细的表来说。明细表的名称为：主表的名称 + 字符Dts。例如：采购定单的名称为：PO_Order，则采购定单的明细表为：PO_OrderDts 对于有主明细的表来说，明细表必须包含两个字段：主表关键字、SN，SN字段的类型为int 型，目的为与主表关键字联合组成明细表的关键字，以及标示明细记录的先后顺序，如1,2,3……。
7）表必须填写描述信息 7）后台表名尽量与前台表名相同，后台独有的表应以_b作为后缀。如r_gggd_b 1.2表字段命名规范 数据库字段的命名必须遵循以下规范： 1）字段名称一般采用名词或动宾短语，且字段名为小写。 2）采用有意义的字段名。字段的名称必须是易于理解，能表达字段功能的英文单词或缩写英文单词，单词首字母必须大写，一般不超过三个英文单词。例如:人员信息表中的电话号码可命名为：Telephone或Tel。产品明细表中的产品名称可用ProductName表示。（推荐一般用完整的英文单词）。 3）系统中所有属于内码字段（仅用于标示唯一性和程序内部用到的标示性字段），名称取为：“ID”，采用整型或长整型数，具体根据可能的数据量确定，增加记录时取最大值加1，该字段通常为主关键字。 4）系统中属于是业务范围内的编号的字段，其代表一定的业务信息，比如资料信息和单据的编号，这样的字段建议命名为：“Code”，其数据类型为varchar，该字段需加唯一索引。 5）在命名表的列时，不要重复表的名称；例如，在名为 Employee 的表中避免使用名为EmployeeLastName 的字段。 5）不要在列的名称中包含数据类型。
数据库设计规范
数据库设计规范 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 数据库设计中需求分析阶段综合各个用户的应用需求（现实世界的需求），在概念设计阶段形成独立于机器特点、独立于各个dbms产品的概念模式（信息世界模型），用e-r图来描述。在逻辑设计阶段将e-r图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图（view）形成数据的外模式。在物理设计阶段根据dbms特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。 1. 需求分析阶段 需求收集和分析，结果得到数据字典描述的数据需求（和数据流图描述的处理需求）。 需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法：调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法（structured analysis，简称sa方法）从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典（data dictionary，简称dd）来描述。 数据字典是各类数据描述的集合，它是关于数据库中数据的描述，即元数据，而不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分(至少应该包含每个字段的数据类型和在每个表内的主外键)。 数据项描述＝｛数据项名，数据项含义说明，别名，数据类型，长度， 取值范围，取值含义，与其他数据项的逻辑关系｝ 数据结构描述＝｛数据结构名，含义说明，组成:｛数据项或数据结构｝｝ 数据流描述＝｛数据流名，说明，数据流来源，数据流去向， 组成:｛数据结构｝，平均流量，高峰期流量｝ 数据存储描述＝｛数据存储名，说明，编号，流入的数据流，流出的数据流， 组成:｛数据结构｝，数据量，存取方式｝ 处理过程描述＝｛处理过程名，说明，输入:｛数据流｝，输出:｛数据流｝, 处理:｛简要说明｝｝
数据库设计规范编码规范
数据库编码规范1 目的？ 为了统一公司软件开发的设计过程中关于数据库设计时的命名规范和具体工作时的编程规范，便于交流和维护，特制定此规范。？ 2 范围？ 本规范适用于全体开发人员，作用于软件项目开发的数据库设计、维护阶段。？ 3 术语？ 数据库对象：在数据库软件开发中，数据库服务器端涉及的对象包括物理结构和逻辑结构的对象。？ 物理结构对象：是指设备管理元素，包括数据文件和事务日志文件的名称、大小、目录规划、所在的服务器计算极名称、镜像等，应该有具体的配置规划。一般对数据库服务器物理设备的管理规程，在整个项目/产品的概要设计阶段予以规划。？
逻辑结构对象：是指数据库对象的管理元素，包括数据库名称、表空间、表、字段/域、视图、索引、触发器、存储过程、函数、数据类型、数据库安全性相关的设计、数据库配置有关的设计以及数据库中其他特性处理相关的设计等。？ 4 设计概要？ 设计环境？ a) ORACLE 11G R2 数据库？ ORACLE 11G R2 ？ 操作系统？ LINUX 6以上版本，显示图形操作界面 b) MS SQL SERVER 2005？ 数据库？ SQL SERVER 2005 企业版？ 打sp3以上补丁和安全补丁？
？ 操作系统？ WINDOWS 2008 SERVER 设计使用工具？ a)使用PowerDesigner 做为数据库的设计工具，要求为主要字段做详尽说明。对于SQL Server 尽量使用企业管理器对数据库进行设计，并且要求对表，字段编写详细的说明（这些将作为扩展属性存入SQL Server中）？ b)通过PowerDesigner 定制word格式报表，并导出word文档，作为数据字典保存，格式。（PowerDesigner v10 才具有定制导出word格式报表的功能）。对于SQL Server 一旦在企业管理器进行数据库设计时加入扩展属性，就可以通过编写简单的工具将数据字典导出。？ c) 编写数据库建数据库、建数据库对象、初始化数据脚本文件？ 设计原则？ a) 采用多数据文件？