Greenplum数据库设计开发规范
- 格式:doc
- 大小:94.00 KB
- 文档页数:17
PostgreSQL数据库开发规范——命名规范设计规范原⽂:命名规范强制】库名、表名限制命名长度,建议表名及字段名字符总长度⼩于等于63。
【强制】对象名(表名、列名、函数名、视图名、序列名、等对象名称)规范,对象名务必只使⽤⼩写字母,下划线,数字。
不要以pg开头,不要以数字开头,不要使⽤保留字。
保留字参考【强制】query中的别名不要使⽤ "⼩写字母,下划线,数字" 以外的字符,例如中⽂。
【推荐】主键索引应以 pk_ 开头,唯⼀索引要以 uk_ 开头,普通索引要以 idx_ 打头。
【推荐】临时表以 tmp_ 开头,⼦表以规则结尾,例如按年分区的主表如果为tbl, 则⼦表为tbl_2016,tbl_2017,。
【推荐】库名最好与应⽤名称⼀致,或便于辨识。
【推荐】不建议使⽤public schema(不同业务共享的对象可以使⽤public schema),应该为每个应⽤分配对应的schema,schema_name最好与user name⼀致。
【推荐】comment不要使⽤中⽂,因为编码可能不⼀样,如果存进去和读取时的编码不⼀致,导致可读性不强。
pg_dump时也必须与comment时的编码⼀致,否则可能乱码。
设计规范【强制】多表中的相同列,必须保证列名⼀致,数据类型⼀致。
【强制】btree索引字段不建议超过2000字节,如果有超过2000字节的字段需要建索引,建议使⽤函数索引(例如哈希值索引),或者使⽤分词索引。
【强制】使⽤外键时,如果你使⽤的PG版本没有⾃动建⽴fk的索引,则必须要对foreign key⼿⼯建⽴索引,否则可能影响references列的更新或删除性能。
postgres=# create table tbl(id int primary key,info text);CREATE TABLEpostgres=# create table tbl1(id int references tbl(id), info text);CREATE TABLEpostgres=# \d tblTable "public.tbl"Column | Type | Modifiers--------+---------+-----------id | integer | not nullinfo | text |Indexes:"tbl_pkey" PRIMARY KEY, btree (id)Referenced by:TABLE "tbl1" CONSTRAINT "tbl1_id_fkey" FOREIGN KEY (id) REFERENCES tbl(id)postgres=# \d tbl1Table "public.tbl1"Column | Type | Modifiers--------+---------+-----------id | integer |info | text |Foreign-key constraints:"tbl1_id_fkey" FOREIGN KEY (id) REFERENCES tbl(id)postgres=# \diList of relationsSchema | Name | Type | Owner | Table--------+----------+-------+----------+-------public | tbl_pkey | index | postgres | tbl(1 row)postgres=# create index idx_tbl1_id on tbl1(id);CREATE INDEX【强制】使⽤外键时,⼀定要设置fk的action,例如cascade,set null,set default。
数据库建设规范数据库作为存储、管理和处理数据的重要工具,在现代信息化建设中起着至关重要的作用。
为了提高数据库的质量和效率,确保数据的安全性和准确性,需要制定一套数据库建设规范。
本文将从数据库设计、数据规范、性能优化和安全保障四个方面详细介绍数据库建设规范。
一、数据库设计在数据库建设的初期阶段,良好的数据库设计能够为后期的开发和维护工作奠定基础。
数据库设计应遵循以下几点规范:1. 数据库表命名规范表名应具有具体的描述性,能够准确表达其所存储的数据内容,并采用小写字母与下划线组合的方式命名,例如"order_info"。
2. 字段命名规范字段名应有明确的含义,避免使用缩写和数字等模糊的命名方式。
同时,字段名也应采用小写字母与下划线组合的方式命名,例如"create_time"。
3. 主键和外键规范每个表应有主键,并使用自增长或唯一性约束来保证主键的唯一性。
同时,在设计关联表时,外键应与关联的主键类型一致。
4. 索引规范为常用作查询条件的字段创建索引,以提高查询效率。
在创建索引时,需要根据实际情况进行选择,避免过多的索引对性能造成负面影响。
二、数据规范数据库中的数据质量对于后续的数据分析和决策产生重要影响。
为了保证数据的一致性和准确性,需要制定以下数据规范:1. 数据类型规范在对字段进行设计时,需要选择合适的数据类型,以节省存储空间,并确保数据的正确性。
例如,对于存储日期时间的字段,应选择合适的日期时间类型。
2. 数据录入规范为了避免数据录入错误,需要制定数据录入规范。
规定数据录入格式、校验规则和必填字段,同时提供数据录入的帮助文档和提示信息,以减少错误的发生。
3. 数据清洗规范对于已有的大规模数据,需要进行数据清洗,剔除重复、错误、缺失和异常数据,以保证数据库中的数据质量。
三、性能优化数据库的性能直接关系到系统的响应速度和用户体验。
为了提高数据库的性能,需要进行以下优化措施:1. 查询优化使用合适的查询方式、优化复杂查询语句、减少不必要的连接和子查询,以提高查询效率。
PostgreSQL数据库设计原则和最佳实践数据库设计是构建一个高效、可扩展和易维护的系统的关键步骤。
PostgreSQL是一种强大的开源关系型数据库管理系统,具有广泛的功能和扩展性。
本文将介绍一些PostgreSQL数据库设计的原则和最佳实践,以帮助您更好地设计和优化数据库。
1. 使用正确的数据类型正确选择合适的数据类型是数据库设计中至关重要的一步。
不同的数据类型在存储和处理数据时有不同的性能和空间开销。
在PostgreSQL中,有许多数据类型可供选择,如整数、浮点数、文本、日期/时间等。
根据数据的特性和需求,选择最合适的数据类型,以减少存储空间的浪费和提高查询性能。
2. 设计合理的表结构在设计数据库表结构时,应遵循一些最佳实践。
首先,确定正确的主键。
主键应该是唯一且稳定的字段,它能够唯一标识一条记录。
其次,避免使用过多的冗余字段,以减少数据冗余和维护成本。
此外,合理设计表之间的关系,并使用外键来实现数据完整性和一致性。
3. 索引优化索引是提高查询性能的关键之一。
在PostgreSQL中,可以使用B-tree、哈希、GiST等索引类型。
在设计索引时,应根据查询的需求和频率进行优化。
不必为每个字段都创建索引,只需要为经常进行搜索和排序的字段创建索引,可以提高查询效率并减少索引的维护成本。
4. 视图和存储过程的使用视图和存储过程是将逻辑封装在数据库中的强大工具。
视图可以简化复杂的查询,并提供数据安全性。
存储过程可以将一系列的SQL语句封装成一个可重复使用的程序单元,提高数据库的性能和可维护性。
5. 使用事务管理事务管理是确保数据的一致性和完整性的关键机制。
在数据库设计中,应合理使用事务,以保证数据的正确性。
只有当一系列的操作都成功完成时,才将数据持久化到数据库中。
6. 避免过度规范化规范化是数据库设计中常用的一种技术,可以减少数据冗余和提高数据的一致性。
然而,过度规范化会导致查询性能下降,增加查询的复杂度。
数据库设计规范数据库设计规范是指在进行数据库设计时需要遵循的一系列规则和准则,以确保数据库的结构和功能能够满足用户需求,并且能够高效地进行数据管理和存储。
本文将介绍一些常见的数据库设计规范,包括命名规范、数据类型选择、索引设计、表关系设计等。
1. 命名规范在数据库设计中,良好的命名规范能够使数据库对象更易于理解和维护。
以下是一些建议:1.1 表名、列名和约束名应使用清晰明了的描述性词汇,避免使用含糊不清或缩写的名称。
1.2 使用统一的命名风格,如下划线命名法(例如:user_name)或者驼峰命名法(例如:userName)。
1.3 避免使用数据库关键字作为对象的名称,以免引起冲突。
2. 数据类型选择选择合适的数据类型对数据库的性能和空间利用是至关重要的。
以下是一些常见的数据类型选择规范:2.1 尽量使用较小的数据类型,以减少存储空间和提高查询性能。
2.2 对于整数类型,根据实际需求选择合适的精度(如TINYINT、SMALLINT、INT等)。
2.3 对于字符串类型,根据实际需求选择合适的长度(如VARCHAR、CHAR等)。
2.4 避免使用文本型字段存储大量的文本数据,可以考虑使用CLOB或BLOB类型。
3. 索引设计合理的索引设计可以加速查询操作,但是过多或不恰当的索引会增加维护成本和写操作的开销。
以下是一些常见的索引设计规范:3.1 为频繁使用作为查询条件的字段添加索引,以提高查询性能。
3.2 避免在较小的表或者稀疏的字段上创建索引,因为这可能导致索引失效并降低性能。
3.3 当需要根据多个字段进行查询时,考虑创建复合索引,以提高查询效率。
4. 表关系设计在数据库设计中,表与表之间的关系是非常重要的。
以下是一些常见的表关系设计规范:4.1 使用主键(Primary Key)和外键(Foreign Key)来建立表与表之间的关联,以确保数据的完整性和一致性。
4.2 避免使用过多的嵌套层次关系,以减少查询的复杂性。
数据库设计指南1. 设计原则1.1. 关于范式如无性能上的必要原因,应该考虑遵循关系数据库理论,达到较高的范式匹配(3NF),避免数据冗余,明确数据间的关系。
如果对性能有较高要求,或者在特定场景达成业务目标的便利性收益高于数据管理影响,可以设计适当的突破范式要求。
1.2. 字符集和编码应当采用Unicode字符集和UTF8编码,此为PostgreSQL 数据库服务器默认设置,并且,如果在创建数据库(实例)时没有特别指定,也将是数据库(实例)的默认设置。
如果有强烈的中华多文字支持要求,如简体汉字、繁体汉字、少数民族文字、日文、韩文等,可以使用GB18030字符集和编码,不建议使用GB2312、GBK。
1.3. 数据库服务器和数据库一个操作系统中只部署 1 个数据库服务器软件。
一个数据库服务器中可以创建多个数据库。
1.4. 表空间对于PostgreSQL 来说,在同一个磁盘分区上建立多个表空间没有太多实际意义。
从合理利用磁盘性能和空间角度,可以分别建立不同的表空间,如:•在高IO 性能的磁盘分区上创建的表空间,可以用来存放经常访问的表和索引。
•在便宜和较低IO 性能的磁盘分区上创建的表空间,可以用来存放很少使用或性能要求不高的归档数据的表。
对于容器部署的数据库,容器内可以使用默认表空间pg_default(路径$PGDATA/base),并映射到容器外宿主机的特定路径下。
非容器部署的数据库,建议在指定的路径下创建表空间。
多个数据库可以共用同一个表空间。
注意: PostgreSQL 中的表空间与 Oracle 不一样,创建PostgreSQL 表空间只要指定名称与数据库文件的目录,而没有具体的大小。
PostgreSQL 表空间不适用“自动扩容”这个概念,存储不足时可以通过扩展表空间所在存储容量,或者在不同存储设备/分区中新建表空间并指定新表使用新表空间来达到扩容目的。
1.5. Schema建议为子系统、业务模块或用户分配对应的schema。
数据库开发规范标准1. 概述本文档旨在制定数据库开发的规范标准,以确保数据库的一致性、可维护性和安全性。
准确遵循本文档中的规定可以提高开发效率并减少潜在问题。
2. 命名规范2.1 数据库对象命名规范- 表名应使用英文单词,采用下划线分隔,避免使用特殊字符和空格。
- 字段名应使用英文单词,采用下划线分隔,避免使用特殊字符和空格。
- 索引名应简明扼要地描述其作用和字段,避免使用含糊不清的命名。
2.2 命名约定- 主键字段应命名为`id`。
- 外键字段应命名为`关联表名_id`的形式,例如`user_id`。
- 创建时间字段应命名为`created_at`,更新时间字段应命名为`updated_at`。
- 布尔类型字段应使用形容词或动词开头,例如`is_deleted`。
3. 数据类型和长度3.1 数据类型选择根据不同的业务需求和数据特性选择合适的数据类型,包括整型、浮点型、字符型、日期时间型等。
3.2 字段长度根据数据内容和业务需求确定字段的长度,避免过长或过短的情况。
4. 约束和索引4.1 主键约束每个表应有一个主键,并设置为自增类型。
主键字段应该是唯一且非空的。
4.2 唯一约束针对需要保证唯一性的字段,添加唯一约束。
4.3 外键约束在关联表的字段上添加外键约束,确保数据的一致性和完整性。
4.4 索引根据查询需求和性能考虑,添加合适的索引。
索引应针对经常进行查询或连接操作的字段。
5. 数据库安全5.1 权限控制分配合适的权限给不同的用户和角色,限制其对数据库的操作。
5.2 定期备份定期备份数据库,以防意外数据丢失或损坏。
5.3 数据加密对需要保密的数据进行加密存储,确保敏感数据的安全性。
6. 数据库设计6.1 范式规范根据数据库设计原则,将数据表设计为满足第三范式的结构,避免数据冗余和不一致。
6.2 数据表关系合理设计数据表之间的关系,确保符合业务逻辑和查询需求。
7. SQL语句规范7.1 缩进和格式化对SQL语句进行适当的缩进和格式化,提高可读性。
数据仓库设计与开发规范1概述2数据仓库设计规范2.1命名规范数据仓库库表的命名规范命名规范➢RAW表:RAW+源表名称➢中间表:MID+源表名称➢如果表名字符长度超过32位,则在源表名称中英文字母缩写替换英文单词表字段命名规范命名规范数据库字段的命名必须遵循以下规范:➢采用有意义的字段名。
字段的名称必须是易于理解,能表达字段功能的英文单词或缩写英文单词,无论是完整英文单词还是缩写英文单词,单词首字母必须大写。
➢系统中属于是业务范围内的编号的字段,其代表一定的业务信息,这样的字段建议命名为:代表当前这字段含意的英文单词+ “ID”➢尽量遵守第三范式的标准(3NF)。
✧表内的每一个值只能被表达一次✧表内的每一行都应当被唯一的标示✧表内不应该存储依赖于其他键的非键信息存储过程命名规范命名规范➢存贮过程的命名请遵循以下命名规范:P_ MID_+ 业务逻辑(英文单词或缩写)如:P_MID_PUB_TRADE_BUY设计规范在存贮过程中必须说明以下内容:➢名称:存贮过程。
➢描述:描述存储过程的作用➢创建者:首次创建此存贮过程的人的姓名。
在此请使用中文全名,不允许使用英文简称。
➢修改者、修改日期、修改原因:如果有人对此存贮过程进行了修改,则必须在此存贮过程的前面加注修改者姓名、修改日期及修改原因。
➢对存贮过程各参数及变量的中文注解。
示例如下:-- =============================================-- procedurename: P_MID_PUB_TRADE_BUY-- description : 公募交易表-- author : 张三-- create date : 2015-07-17--source_table : raw_tp_dis_trade_app_rec--target_table : MID_PUB_TRADE_BUY--modified :修改日期:2015-07-20 修改原因及内容-- =============================================视图命名规范命名规范➢视图的命名请遵循以下命名规范:V_ +_操作的表名(不带前缀)或功能的英文单词或英文单词缩写。
目录第一章前言................................................................................................... 错误!未指定书签。
1.1文档目的................................................................................................ 错误!未指定书签。
1.2预期读者................................................................................................ 错误!未指定书签。
1.3参考资料................................................................................................ 错误!未指定书签。
第二章设计规范 ........................................................................................... 错误!未指定书签。
2.1数据库对象数量 .................................................................................... 错误!未指定书签。
2.2表创建规范............................................................................................ 错误!未指定书签。
2.3表结构设计............................................................................................ 错误!未指定书签。
2.3.1字段命名 ........................................................................................... 错误!未指定书签。
2.3.2数据类型 ........................................................................................... 错误!未指定书签。
2.3.3数据分布 ........................................................................................... 错误!未指定书签。
2.3.4分区 ................................................................................................... 错误!未指定书签。
2.3.5压缩存储 ........................................................................................... 错误!未指定书签。
2.3.6索引设计 ........................................................................................... 错误!未指定书签。
2.4其他数据库对象设计 ............................................................................ 错误!未指定书签。
2.4.1schema............................................................................................... 错误!未指定书签。
2.4.2视图 ................................................................................................... 错误!未指定书签。
2.4.3临时表和中间表 ............................................................................... 错误!未指定书签。
第三章SQL开发规范 .................................................................................... 错误!未指定书签。
3.1基本要求................................................................................................ 错误!未指定书签。
3.2WHERE条件................................................................................................ 错误!未指定书签。
3.3分区字段使用 ........................................................................................ 错误!未指定书签。
3.4表关联.................................................................................................... 错误!未指定书签。
3.5排序语句................................................................................................ 错误!未指定书签。
3.6嵌套子查询............................................................................................ 错误!未指定书签。
3.7UNION/UNION ALL..................................................................................... 错误!未指定书签。
3.8高效SQL写法的建议............................................................................ 错误!未指定书签。
第一章前言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语句中表名对大小写不敏感。
但不允许在建表语句中使用双引号(“”)包括表名,这样会影响系统表中存储的名称,使得表名存在大小写或特殊字符。
表命名也不允许出现中文字。
2、单个数据库的数据表数量建议不要超过10万张;3、禁止使用二级分区表,因为二级分区表会造成表对象数量的急剧膨胀;4、由于过多的数据文件会导致操作系统对文件的操作效率降低,直接影响到数据库的管理效率。
如果数据文件数量过多,建议增加多个表空间,把数据表均匀分布到不同的表空间。
每个表空间目录下的数据文件数量,应控制在80万以内。
文件数统计可以直接到某个Segment实例目录下指定的表空间目录下统计。
5、创建数据表(DDL)的时候(不含临时表和程序中使用的中间表),必须使用tablespace 子句指定用于存储的表空间,而不是把所有表都存储在默认表空间;例如:6、对于数据量超过1TB的大表,需从应用设计方面,考虑对大表进行优化,例如是否可划分为历史数据表和当前数据表,并分开存放;是否应采用压缩存储节省空间;是否合理分区;是否应定期清理数据等等。
2.3 表结构设计2.3.1 字段命名表字段的命名,与表名类似。
在GP系统表中保存的表名称都是以小写保存。
通常SQL语句中字段名称对大小写不敏感。
但不允许在建表语句中使用双引号(“”)包括字段名,这样会影响系统表中存储的名称,使得表名存在大小写或特殊字符。
字段命名也不允许出现中文字。
2.3.2 数据类型数据类型的定义与相关数据的加载和使用紧密相关,数据类型的定义决定了数据所占用的空间大小,因此,必须慎重设计GP数据仓库数据表的字段类型。