Rule 2.1: Avoiding Direct Usage of Built-in Databases Such As postgres and gaussdb
Impact of rule violation:
- If the code or the compatibility setting of the built-in databases does not meet service requirements, you may need to migrate your data again.
- The time for changes to be applied may be prolonged if all services use built-in databases.
Solution:
- To meet the specific requirements of each service, it is recommended to create a dedicated database and allocate it accordingly.
Rule 2.2: Selecting the Suitable Database Code During Database Creation
Impact of rule violation:
- Selecting the wrong database code may result in displaying garbled characters, and it is not possible to directly change the database code. In such cases, you will need to create a database and import the data again.
Solution:
- It is advisable to set the ENCODING to the UTF-8 format during database creation, unless there are specific requirements for a different encoding.
Rule 2.3: Choosing the Right Database Type for Compatibility with the Database to Be Created
Impact of rule violation:
- Selecting the wrong type can lead to behavior inconsistencies after migrating the database from a different vendor to GaussDB(DWS). Unfortunately, it is not possible to directly change the compatibility setting. The only solution is to create a database and import the data again.
Solution:
- GaussDB(DWS) supports compatibility with databases like Teradata, Oracle, and MySQL. You can specify DBCOMPATIBILITY to set the compatible database type when creating a database.
Suggestion 2.4: Creating the Objects with Associated Calculations in the Same Database
Impact of rule violation:
- Cross-database access tends to have poorer performance compared to performing operations within the same database.
Solution:
- If multiple databases are created, it is advisable to create the objects requiring associated calculations in the same database.