openGauss应用开发指南（1）

数据查询请求处理过程

数据请求分为创建、删除、修改和查询，处理过程大致相同。以数据查询过程为例，展现客户端如何与openGauss sever进行交互。数据查询请求过程如图1所示所示，创建、删除和修改请求处理过程只在图中第7步有差异。

图 1 openGauss服务响应流程

开发设计建议

• 开发设计规范概述

• 数据库对象命名

• 数据库对象设计

• 工具对接

• SQL编写

 

开发设计建议概述

本开发设计建议约定数据库建模和数据库应用程序开发过程中，应当遵守的设计规范。依据这些规范进行建模，能够更好的契合openGauss的处理架构，输出更高效的业务SQL代码。

本开发设计建议中所陈述的“建议”和“关注”含义如下：

• 建议：用户应当遵守的设计规则。遵守这些规则，能够保证业务的高效运行；违反这些规则，将导致业务性能的大幅下降或某些业务逻辑错误。
• 关注：在业务开发过程中客户需要注意的细则。用于标识容易导致客户理解错误的知识点（实际上遵守SQL标准的SQL行为），或者程序中潜在的客户不易感知的默认行为。

 

数据库对象命名

数据库对象命名需要满足约束：

• 标识符非时序表长度不超过63个字节，时序表（当前特性是实验室特性，使用时请联系华为工程师提供技术支持）长度不超过53个字符。

• 标识符以字母或下划线开头，中间字符可以是字母、数字、下划线、$、#。

• 若标识符被双引号（""）包含，则可以使用合法字符的任意组合，如"123gs_column"。

• 标识符不区分大小写，只有被双引号包含才区分大小写。

• 【建议】避免使用保留或者非保留关键字命名数据库对象。

  

   说明： 可以使用select * from pg_get_keywords()查询openGauss的关键字，或者在关键字章节中查看。

• 【建议】避免使用双引号括起来的字符串来定义数据库对象名称，除非需要限制数据库对象名称的大小写。数据库对象名称大小写敏感会使定位问题难度增加。

• 【建议】数据库对象命名风格务必保持统一。

  • 增量开发的业务系统或进行业务迁移的系统，建议遵守历史的命名风格。
  • 建议使用多个单词组成，以下划线分割。
  • 数据库对象名称建议能够望文知意，尽量避免使用自定义缩写（可以使用通用的术语缩写进行命名）。例如，在命名中可以使用具有实际业务含义的英文词汇或汉语拼音，但规则应该在数据库实例范围内保持一致。
  • 变量名的关键是要具有描述性，即变量名称要有一定的意义，变量名要有前缀标明该变量的类型。

• 【建议】表对象的命名应该可以表征该表的重要特征。例如，在表对象命名时区分该表是普通表、临时表还是非日志表：

  • 普通表名按照数据集的业务含义命名。
  • 临时表以“tmp_+后缀”命名。
  • 非日志表以“ul_+后缀”命名。
  • 外表以“f_+后缀”命名。
  • 不创建以redis_为前缀的数据库对象。
  • 不创建以mlog_和以matviewmap_为前缀的数据库对象。

• 【建议】非时序表对象命名建议不要超过63字节。如果过该长度内核会对表名进行截断，从而造成和设置值不一致的现象。且在不同字符集下，可能造成字符被截断，出现预期外的字符。

 

数据库对象设计

• Database和Schema设计

• 表设计

• 字段设计

• 约束设计

• 视图和关联表设计

Database和Schema设计

openGauss中可以使用Database和Schema实现业务的隔离，区别在于Database的隔离更加彻底，各个Database之间共享资源极少，可实现连接隔离、权限隔离等，Database之间无法直接互访。Schema隔离的方式共用资源较多，可以通过grant与revoke语法便捷地控制不同用户对各Schema及其下属对象的权限。

• 从便捷性和资源共享效率上考虑，推荐使用Schema进行业务隔离。
• 建议系统管理员创建Schema和Database，再赋予相关用户对应的权限。

Database设计建议

• 【规则】在实际业务中，根据需要创建新的Database，不建议直接使用数据库实例默认的postgres数据库。
• 【建议】一个数据库实例内，用户自定义的Database数量建议不超过3个。
• 【建议】为了适应全球化的需求，使数据库编码能够存储与表示绝大多数的字符，建议创建Database的时候使用UTF-8编码。
• 【关注】创建Database时，需要重点关注字符集编码（ENCODING）和兼容性（DBCOMPATIBILITY）两个配置项。openGauss支持A、B、C和PG四种兼容模式，分别表示兼容O语法、MY语法、TD语法和POSTGRES语法，不同兼容模式下的语法行为存在一定差异，默认为A兼容模式。
• 【关注】Database的owner默认拥有该Database下所有对象的所有权限，包括删除权限。删除权限影响较大，请谨慎使用。

Schema设计建议

• 【关注】如果该用户不具有sysadmin权限或者不是该Schema的owner，要访问Schema下的对象，需要同时给用户赋予Schema的usage权限和对象的相应权限。
• 【关注】如果要在Schema下创建对象，需要授予操作用户该Schema的create权限。
• 【关注】Schema的owner默认拥有该Schema下对象的所有权限，包括删除权限。删除权限影响较大，请谨慎使用。