Tables, keys, and reusable partials

Add a reusable column set#

Use a TablePartial for columns shared by several tables. Its name participates in completion and navigation; the diagram expands the fields into each table.

TablePartial timestamps {
  created_at timestamp [not null, default: `now()`]
  updated_at timestamp [not null, default: `now()`]
}

Enum order_state {
  pending
  paid
  cancelled
}

Table shop.orders {
  ~timestamps
  tenant_id uuid [not null]
  id uuid [not null]
  state order_state [not null, default: 'pending']
  total numeric(12,2) [not null]

  indexes {
    (tenant_id, id) [pk, name: 'orders_pk']
    (tenant_id, state) [name: 'orders_state_idx']
  }

  checks {
    `total >= 0` [name: 'orders_total_nonnegative']
  }
}

Check completion at each level#

Invoke completion on the enum type, the ~timestamps reference, and an index column. Navigate from each reference to its declaration. Open Structure view to find the table without scanning a long file.

The composite primary key belongs in indexes; marking id alone as [pk] would describe a different key. In a tenant-scoped design, include the tenant column when writing foreign keys to that composite key.

Defaults and checks#

A quoted default such as 'pending' is a value. Backticks around now() or a check expression preserve SQL expressions. DBML Pro carries these details through the schema model, but the target database dialect still determines their executable meaning.

Export SQL and inspect the primary key, default, and named check before using the result as a migration. A diagram badge proves that a key is modeled; it does not prove the current database has that key.

Reuse across files#

Move the partial into a module when several schemas share it, then import it explicitly. Follow Modules and visibility for the difference between private imports and re-exported declarations.