Relational Database ServiceRelational Database Service

Compute
Elastic Cloud Server
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Networking
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
Domain Name Service
VPC Endpoint
Cloud Connect
Enterprise Switch
Security & Compliance
Anti-DDoS
Web Application Firewall
Host Security Service
Data Encryption Workshop
Database Security Service
Advanced Anti-DDoS
Data Security Center
Container Guard Service
Situation Awareness
Managed Threat Detection
Compass
Cloud Certificate Manager
Anti-DDoS Service
Databases
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GaussDB NoSQL
GaussDB(for MySQL)
Distributed Database Middleware
GaussDB(for openGauss)
Developer Services
ServiceStage
Distributed Cache Service
Simple Message Notification
Application Performance Management
Application Operations Management
Blockchain Service
API Gateway
Cloud Performance Test Service
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
DevCloud
ProjectMan
CodeHub
CloudRelease
CloudPipeline
CloudBuild
CloudDeploy
Cloud Communications
Message & SMS
Cloud Ecosystem
Marketplace
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP License Service
Support Plans
Customer Operation Capabilities
Partner Support Plans
Professional Services
enterprise-collaboration
Meeting
IoT
IoT
Intelligent EdgeFabric
DeveloperTools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Updated at: Apr 02, 2022 GMT+08:00

Database Usage Specifications

Naming

  • The names of objects (such as databases, tables, and indexes) must be no more than 63 bytes. Note that some characters (such as Chinese characters) may occupy multiple bytes.
  • Do not use reserved database keywords in object names or start an object name with pg, a digit, or an underscore (_).

Table Design

  • The table structure must be designed in advance to avoid frequent structure changes, such as adding fields or changing data types.
  • The number of fields in a single table cannot exceed 64.
  • Create partitioned tables for the tables whose data needs to be deleted periodically. For example, you can create partitions by time and delete data from the partitions using DROP or TRUNCATE.
  • Use proper data types for table fields. For example, do not use the character type for numeric or date data.
  • When using the numeric data type, ensure that the values are within allowed ranges and meet the precision requirements.

Index Design

  • Design primary keys or unique keys for tables that require logical replication.
  • When creating a foreign key, specify the action for deleting or updating the foreign key, for example, ON DELETE CASCADE.
  • Create indexes on fields that are frequently used (such as fields for data query and sorting).
  • Create partial indexes for queries using fixed conditions.
  • Create expression indexes for queries using conditional expressions.
  • A single table cannot contain too many indexes because indexes also occupy storage. For example, single-column indexes should be less than 5, while composite indexes should be less than 3.

SQL Design

  • Specify the required fields to be returned in a query.
  • Only use IS NULL or IS NOT NULL to determine whether a field is NULL.
  • Use NOT EXISTS instead of NOT IN in a query.
  • Use UNION ALL instead of UNION to concatenate result sets.
  • Use TRUNCATE instead of DELETE to delete an entire table.
  • Submit data changes in large transactions in batches to prevent high pressure during transaction commit or rollback.

Security

  • Do not assign the public role to the owner of an application database object. Assign a specific role to the owner.
  • A database password must meet complexity requirements.
  • Do not use the database superuser as the development and test account of your service system.
  • Allocate a unique database account for each service.
  • When accessing an object, explicitly specify the schema of the object to avoid accessing objects with the same name in other schemas.

Did you find this page helpful?

Failed to submit the feedback. Please try again later.

Which of the following issues have you encountered?







Please complete at least one feedback item.

Content most length 200 character

Content is empty.

OK Cancel