Multi-DB Setting
Cals Platz is a product that services multiple tenants within a single application, structured around tenant-based service delivery.
The operation and screen logic of the tenant application are based on metadata configured in the Studio. This metadata and application data are classified into three types based on storage methods.
1. Type A
Type A refers to configuration-related data registered in the Studio that is simultaneously stored in both the Console DB and the Application DB. The application functionality operates based on the system metadata in the Console DB, with data also stored in the Application DB for reference.
Type A Table Examples:
qt_account
,qt_comm_code
,qt_sym_str
, etc.Application DB Data Creation Time:
- Created by tenant developers in the Studio environment.
- For App environments: Created at the Deploy stage.
- For Sandbox environments: Created after Provisioning and then Deploy.
- For Production environments: Created after Provisioning and then Publish.
2. Type B
Type B refers to system-generated data created by the application's system functions, which exist only in the Application DB.
Type B Table Examples:
qt_user
,qt_file_history
,qt_pwp
,qt_pwp_item
, etc.Application DB Data Creation Time:
- Created when an administrator or general user sets up or uses functions in the web or mobile system environment.
qt_key_master
: For key management handled by the application, this table is stored and managed within a secure schema. Therefore, although it is stored in the target DB instance specified by the DB model type, the schema remains fixed.
3. Type C
Type C refers to data stored as metadata configured in the Studio, which is stored only in the Console DB.
- Type C Table Examples:
qt_menu
,qt_screen
,qt_action
, etc.
The Tenant DB model refers to the method of storing Type A and Type B data in the Application DB.
The DB configuration in tenant infrastructure provides three models:
Model | Characteristics | Description |
---|---|---|
Silo | Multi DB | A method using a separate database for each tenant. |
Bridge | One DB Multi Schema | A method using the same database with separate schemas for each tenant. |
Pool | One DB (Default) | A method that provides tenant data separated by Tenant ID within tables in a single DB. |
Guidelines for the initial setup of each model and how to change DB settings during development will be provided.