-
数据库对象命名 数据库对象命名需要满足约束： 标识符表长度不超过63个字节。 标识符以字母或下划线开头，中间字符可以是字母、数字、下划线、$、#。 若标识符被双引号（""）包含或者B模式下被反引号（``）包含，则可以使用合法字符的任意组合，如"123gs_column"。 标识符不区分大小写，只有被双引号包含或者B模式下被反引号（``）包含才区分大小写。 不支持gsql快捷命令（除了\sf）查询反引号包含的对象名。 避免使用保留或者非保留关键字命名数据库对象。 可以使用SELECT * FROM pg_get_keywords()查询
GaussDB 的关键字，或者在关键字章节中查看。 避免使用双引号括起来的字符串来定义数据库对象名称，除非需要限制数据库对象名称的大小写。数据库对象名称大小写敏感会使定位问题难度增加。 数据库对象命名风格务必保持统一。 增量开发的业务系统或进行业务迁移的系统，建议遵守历史的命名风格。 建议使用多个单词组成，以下划线分割。 数据库对象名称建议能够望文知意，尽量避免使用自定义缩写（可以使用通用的术语缩写）进行命名。例如，在命名中可以使用具有实际业务含义的英文词汇或汉语拼音，但规则应该在数据库实例范围内保持一致。 变量名的关键是要具有描述性，即变量名要有一定的意义，变量名要有前缀标明该变量的类型。 表对象的命名应该可以表征该表的重要特征。例如，在表对象命名时区分该表是普通表、临时表还是非日志表。 普通表名按照数据集的业务含义命名。 临时表以“tmp_+后缀”命名。 非日志表以“ul_+后缀”命名。 外表以“f_+后缀”命名。 不创建以redis_为前缀的数据库对象。 不创建以mlog_和以matviewmap_为前缀的数据库对象。 不创建以gs_role_为前缀的数据库对象。 表对象命名建议不要超过63字节。如果超过该长度内核会对表名进行截断，从而造成和设置值不一致的现象，且在不同字符集下，可能造成字符被截断，出现预期外的字符。 父主题： 开发设计建议
-
数据加载和卸载 在INSERT语句中显式设置插入的字段列表。例如： 1 INSERT INTO task(name,id,comment) VALUES ('task1','100','第100个任务');
在批量数据入库之后，或者数据增量达到一定阈值后，建议对表进行ANALYZE操作，防止统计信息不准确而导致的执行计划劣化。 如果要清理表中的所有数据，建议使用TRUNCATE TABLE方式，不要使用DELETE TABLE方式。DELETE TABLE方式删除性能差，且不会释放那些已经删除了的数据占用的磁盘空间。
-
DDL 在GaussDB中，建议DDL（建表、COMMENT等）操作统一执行。在批处理作业中尽量避免DDL操作，避免大量并发事务对性能的影响。 在非日志表（unlogged table）使用完后，立即执行数据清理（TRUNCATE）操作。因为在异常场景下，GaussDB不保证非日志表(unlogged table)数据的安全性。 临时表和非日志表的存储方式建议和基表相同。 索引字段的总长度不超过50字节。否则，索引大小会膨胀比较严重，带来较大的存储开销，同时索引性能也会下降。 不要使用DROP…CASCADE方式删除对象，除非已经明确对象间的依赖关系，以免误删。 详细DDL语法请参见DDL语法一览表。
-
开发设计建议概述 开发设计建议约定数据库建模和数据库应用程序开发过程中，应当遵守的设计规则。根据这些规则进行建模，能够更好地契合GaussDB的处理架构，输出更高效的业务SQL代码。 开发设计建议中所陈述的“建议”和“关注”含义如下： 建议：用户应当遵守的设计规则。遵守这些规则，能够保证业务的高效运行。违反这些规则，将导致业务性能的大幅下降或某些业务逻辑错误。 关注：在业务开发过程中用户需要注意的细则。用于标识容易导致用户理解错误的知识点（实际上遵守SQL标准的SQL行为），或者程序中潜在的用户不易感知的默认行为。 父主题： 开发设计建议
-
数据库对象命名 数据库对象命名需要满足约束： 标识符表长度不超过63个字节。若需要对建有全局二级索引（GSI）的表执行COPY、GDS数据导入操作，则表名长度不超过38个字节。 标识符以字母或下划线开头，中间字符可以是字母、数字、下划线、$、#。 若标识符被双引号（""）包含或者MYSQL模式下被反引号（``）包含，则可以使用合法字符的任意组合，如"123gs_column"。 标识符不区分大小写，只有被双引号包含或者MYSQL模式下被反引号（``）包含才区分大小写。 不支持gsql快捷命令（除\sf）查询反引号包含的对象名。 避免使用保留或者非保留关键字命名数据库对象。 可以使用SELECT * FROM pg_get_keywords()查询GaussDB的关键字，或者在关键字章节中查看。 避免使用双引号括起来的字符串来定义数据库对象名称，除非需要限制数据库对象名称的大小写。数据库对象名称大小写敏感会使定位问题难度增加。 数据库对象命名风格务必保持统一。 增量开发的业务系统或进行业务迁移的系统，建议遵守历史的命名风格。 建议使用多个单词组成，以下划线分割。 数据库对象名称建议能够望文知意，尽量避免使用自定义缩写（可以使用通用的术语缩写进行命名）。例如，在命名中可以使用具有实际业务含义的英文词汇或汉语拼音，但规则应该在集群范围内保持一致。 变量名的关键是要具有描述性，即变量名要有一定的意义，变量名要有前缀标明该变量的类型。 表对象的命名应该可以表征该表的重要特征。例如，在表对象命名时区分该表是普通表、临时表还是非日志表： 普通表名按照数据集的业务含义命名。 临时表以“tmp_+后缀”命名。 非日志表以“ul_+后缀”命名。 外表以“f_+后缀”命名。 不创建以redis_为前缀的数据库对象。 不创建以pgxc_redistb为命名的数据库对象。 不创建以mlog_和以matviewmap_为前缀的数据库对象。 不创建以gs_role_为前缀的数据库对象。 表对象命名建议不要超过63字节。如果超过该长度内核会对表名进行截断，从而造成实际名称和设置值不一致的现象，且在不同字符集下，可能造成字符被截断，出现预期外的字符。 若需要对建有全局二级索引（GSI）的表执行COPY、GDS数据导入操作，则表名长度不超过38个字节。如果超过该长度，COPY、GDS导入过程中创建的临时表，可能触发表名截断，进而引发数据导入流程中断，出现预期外的字符等问题。 父主题： 开发设计建议
-
数据加载和卸载 在INSERT语句中显式设置插入的字段列表。例如： 1 INSERT INTO task(name,id,comment) VALUES ('task1','100','第100个任务');
在批量数据入库之后，或者数据增量达到一定阈值后，建议对表进行ANALYZE操作，防止统计信息不准确而导致的执行计划劣化。 如果要清理表中的所有数据，建议使用TRUNCATE TABLE方式，不要使用DELETE TABLE方式。DELETE TABLE方式删除性能差，且不会释放那些已经删除了的数据占用的磁盘空间。
-
DDL 在GaussDB中，建议DDL（建表、COMMENT等）操作统一执行。在批处理作业中尽量避免DDL操作，避免大量并发事务对性能的影响。 在非日志表（unlogged table）使用完后，立即执行数据清理（TRUNCATE）操作。因为在异常场景下，GaussDB不保证非日志表(unlogged table)数据的安全性。 临时表和非日志表的存储方式建议和基表相同。 索引字段的总长度不超过50字节。否则，索引大小会膨胀比较严重，带来较大的存储开销，同时索引性能也会下降。 不要使用DROP…CASCADE方式删除对象，除非已经明确对象间的依赖关系，以免误删。 详细DDL语法请参见DDL语法一览表。
-
开发设计建议概述 开发设计建议约定数据库建模和数据库应用程序开发过程中，应当遵守的设计规范。依据这些规范进行建模，能够更好地契合GaussDB的分布式处理架构，输出更高效的业务SQL代码。 开发设计建议中所陈述的“建议”和“关注”含义如下： 建议：用户应当遵守的设计规则。遵守这些规则，能够保证业务的高效运行；违反这些规则，将导致业务性能的大幅下降或某些业务逻辑错误。 关注：在业务开发过程中用户需要注意的细则。用于标识容易导致用户理解错误的知识点（实际上遵守SQL标准的SQL行为），或者程序中潜在的用户不易感知的默认行为。 父主题： 开发设计建议
-
术语约定 本规范采用以下的术语描述： 规格：数据库规格，编程、设计必须遵守的原则，否则数据库将报错。 规则：编程、设计强制遵守的原则。 建议：编程、设计必须加以考虑的原则。 说明：对规则或建议进行必要的解释。 示例：对规则或建议进行正或反方面的举例。 分片： 将一个表中的数据按照指定的策略拆分并存储至多个DN上的同名表中，这些表中存储的数据互不重叠，可以理解为“表的水平分库”，举例：t_user表按主键userId Hash拆分到数据库的4个不同DN中，这就是4个分片，每个分片内都有一张同名的t_user表。
-
简介 本规范以产品生命周期为主线，详细描述产品设计和开发流程过程中与数据库相关的设计和开发规范。 规范以提高可读性、代码质量为原则，强调实用性、可操作性，对数据库开发容易产生问题的地方做出了明确的规定。主要包括下列内容： 设计规范包括：数据库设计、性能设计。 编程规范包括：排版、命名、注释、语法、脚本、数据库编程、安装部署和安全规范。 同时，在必要时，对部分规范给出细则及具体的范例。 该开发规范仅作为参考，具体规范应结合应用技术架构及规划由数据库使用者综合评估并实施。
-
简介 本规范以产品生命周期为主线，详细描述产品设计和开发流程过程中与数据库相关的设计和开发规范。 规范以提高可读性、代码质量为原则，强调实用性、可操作性，对数据库开发容易产生问题的地方做出了明确的规定。主要包括下列内容： 设计规范包括：数据库设计、性能设计。 编程规范包括：排版、命名、注释、语法、脚本、数据库编程、安装部署和安全规范。 同时，在必要时，对部分规范给出细则及具体的范例。 该开发规范仅作为参考，具体规范应结合应用技术架构及规划由数据库使用者综合评估并实施。
-
简介 本规范以产品生命周期为主线，详细描述产品设计和开发流程过程中与数据库相关的设计和开发规范。 规范以提高可读性、代码质量为原则，强调实用性、可操作性，对数据库开发容易产生问题的地方做出了明确的规定。主要包括下列内容： 设计规范包括：数据库设计、性能设计。 编程规范包括：排版、命名、注释、语法、脚本、数据库编程、安装部署和安全规范。 同时，并在必要时，对部分规范给出细则及具体的范例。 该开发规范仅作为参考，具体规范应结合应用技术架构及规划由数据库使用者综合评估并实施。
-
术语约定 本规范采用以下的术语描述： 规格：数据库规格，编程、设计必须遵守的原则，否则数据库将报错。 规则：编程、设计强制遵守的原则。 建议：编程、设计必须加以考虑的原则。 说明：对规则或建议进行必要的解释。 示例：对规则或建议进行或正或反方面的举例。 分片： 将一个表中的数据按照指定的策略拆分并存储至多个DN上的同名表中，这些表中存储的数据互不重叠，可以理解为“表的水平分库”，举例：t_user表按主键userId Hash拆分到数据库的4个不同DN中就是4个分片，每个分片内都有一张同名的t_user表。
-
规则4.2 避免同时对多个协同分析外表进行跨集群并发访问 原理说明：在A集群通过协同分析访问B集群数据时，A集群所有DN会与B集群CN建立连接和活跃会话。 违反规范的影响： B集群（远端集群）中CN压力过大，导致连接和活跃会话资源超限，访问异常。 方案建议： 应尽量使用外表单表访问并避免并发，避免多外表关联查询；无法避免并发场景时，并发数需根据A集群DN数及B集群常规业务量进行计算和限制，并适当调大max_active_statements和max_connections值。
-
简介 本规范以产品生命周期为主线，详细描述产品设计和开发流程过程中与数据库相关的设计和开发规范。 规范以提高可读性、代码质量为原则，强调实用性、可操作性，对数据库开发容易产生问题的地方做出了明确的规定。主要包括下列内容： 设计规范包括：数据库设计、性能设计。 编程规范包括：排版、命名、注释、语法、脚本、数据库编程、安装部署和安全规范。 同时，在必要时，对部分规范给出细则及具体的范例。 该开发规范仅作为参考，具体规范应结合应用技术架构及规划由数据库使用者综合评估并实施。
