Choosing the Schema Settings for the Project

To define the release pipeline contents, you configure the project to define the database schema where database objects reside.

Smaller applications may work with only one schema.
Medium-sized applications may work with multiple schema.
Medium-to-large applications may work with multiple databases.
Large applications may require multiple projects, possibly divided by their function for the application.

Managed Schema and Tracking Schema

The managed schema refers to the schema where managed SQL objects are stored.

The tracking schema is a location for Datical DB to store the operations history.

The operations history (or changelog) is stored in two tables:

DATABASECHANGELOG
DATABASECHANGELOGLOCK

Characteristics of Schema Settings

Choose the schema setting that matches the database requirements of your application (or functional sections of it).

Project Type	Characteristics
Single-schema	Manages only one schema Tracking tables are kept in the managed schema. Note: you can use a multi-schema project with only one schema if you want to keep the tracking tables separate from the managed database objects. Schema names can be different from step to step Cannot add schema
Multi-schema	Manages one to many schema. Convenient for Oracle databases. Limited to one database per project for other database types (SQL Server, DB2, EDB Postgres). Tracking tables can be assigned to a separate schema just for them. Note: this can be an advantage even for projects that require only one schema. Database type must be the same across release pipeline steps. For a list of database types, see Hardware, Software, and Database Requirements. Each row represents a database type. For example, EDB Postgres and PostgreSQL Community are different database types. Schema names must be the same across release pipeline steps Can add schema
Multi-database	SQL Server only Implicitly multi-schema as well Manages one to many databases. One to many schema can be managed in each database Tracking tables can be assigned to a separate schema just for them Schema names must be the same across release pipeline steps Can add databases Can add schema Most customers who use multi-database configuration use properties for schema names

Projects, Steps, and Schema

A project defines the managed schema. All steps in the release pipeline use it.

Each project defines the project steps that make up the release pipeline.

Each step contains configuration information:

Connection to the database
Schema to use (if multi-schema)
Configuration settings for the step

Schema Role and Connection by Database Type

The use of schema in database organization varies by database type. The following list summarizes its use and provides a summary of how Datical DB connects to a database of its type.

Oracle

Schema is the top level and is associated with the database user. Database objects are under the schema.

Connection parameters:

Hostname:Port (default port 1521)
Service Name (default orcl) or SID
User credentials (or Deferred Credentials setting)

SQL Server

Database is the top level. Schema provide a grouping for database objects. A database may also be managed by a database instance. Multiple database instances are allowed to run on the same host.

Connection parameters:

Hostname:Port default port 1433)
Application Name (Datical DB)
Database
Database Instance (if applicable)
User credentials (or Deferred Credentials setting)

DB2

Database is the top level. Schema provide a grouping for database objects.

Connection parameters:

Hostname:Port (default port 50000)
Database
User credentials (or Deferred Credentials setting)

EDB Postgres

Database is the top level. Schema provide a grouping for database objects.

Connection parameters:

Hostname:Port (default port 5432)
Database
User credentials (or Deferred Credentials setting)