dbx/docs/content/docs/table-structure.mdx

---
title: Table Structure Editor
description: Inspect and edit columns, indexes, foreign keys, and triggers and review dialect-specific DDL before execution.
---

The table structure editor keeps single-table metadata and a change draft in a persistent tab. DBX enables only operations that the active database capability can generate reliably and shows the final DDL before save.

## Open the Editor

- Right-click a table and choose **View structure** or **Edit structure**
- Open from a column node and focus that column
- Open from an index node and focus that index
- Open from table information in the data grid
- Open the same table from Object Browser or a DDL action

The editor retains the active tab, scroll position, column widths, and local column order while you move between structure and data.

## Structure Tabs

| Tab | Main contents |
| --- | --- |
| Columns | Name, type, length/precision, nullability, default, primary key, identity, charset, collation, comment |
| Indexes | Name, columns, type, unique state, included columns, filter, comment, and rebuild action |
| Foreign keys | Local columns, target table/columns, `ON DELETE`, and `ON UPDATE` |
| Triggers | Trigger metadata, source, and supported create/edit/drop actions |
| DDL | Current table definition or driver-generated structure SQL |

When the database does not provide a metadata class, the related tab is hidden, read-only, or displays a capability explanation.

## Column Editing

Depending on database capability, you can:

- Add a column or insert after the current selection
- Drop, rename, and alter columns
- Change type, length, precision, scale, and database-specific length units
- Change `NULL`, default, primary key, identity, charset, collation, and comment
- Use quick picks for common default values
- Drag columns to change order

Column reorder has two meanings:

- MySQL and other databases with physical column-order DDL generate a real reorder
- Some databases save only the local display order in DBX without changing physical structure

New-table creation can use preset fields from settings for common primary keys, timestamps, or audit columns.

## Indexes, Foreign Keys, and Triggers

Index capabilities vary by dialect and can include:

- Create, drop, or rebuild an index
- Standard, unique, and database-specific index types
- Included columns or filters on PostgreSQL, SQL Server, and similar databases
- Index comments where supported
- Automatic names for new indexes with editable values

Foreign-key editing covers column mappings and update/delete actions. Trigger editing depends on source retrieval and safe DDL generation; unsupported databases can still expose source or copyable DDL.

## DDL Preview

Edits do not immediately change the database. Before save, DBX generates highlighted dialect-specific SQL such as:

- `ALTER TABLE ... ADD/DROP/RENAME/MODIFY COLUMN`
- Default, `NULL`, primary-key, and comment changes
- `CREATE INDEX`, `DROP INDEX`, and rebuild operations
- Foreign-key and trigger DDL
- Table-rebuild steps when SQLite requires them

Copy the complete DDL for code review or execution through a migration tool.

<Callout type="warn">Dropping columns, converting types, tightening `NULL`, changing primary keys, physical reorder, and table rebuilds can lock tables or lose data. Review execution impact, backups, and rollback plans in production.</Callout>

## Save Workflow

<Steps>
  <Step>
    ### Read the latest structure

    Confirm that columns, indexes, foreign keys, and triggers are loaded. Refresh first if another client recently changed the table.

  </Step>
  <Step>
    ### Build a local draft

    Add, edit, remove, or reorder objects. Deletions remain pending and are not executed yet.

  </Step>
  <Step>
    ### Review DDL

    Verify qualification, types, defaults, constraints, indexes, and statement order.

  </Step>
  <Step>
    ### Execute and refresh

    Execute after review. Production scope enters production-write confirmation again, and DBX reloads structure after success.

  </Step>
</Steps>

## Dialect and Capability Differences

| Dialect/database | Typical behavior |
| --- | --- |
| MySQL / MariaDB compatible | Broad column properties, physical reorder, primary key, index, foreign key, and comment coverage |
| PostgreSQL / Gauss-compatible | Dialect-aware type/default/null/comment, included/filtered indexes, foreign keys, and related DDL |
| SQLite | Some complex column changes use a safe table-rebuild strategy |
| DuckDB | Supports common column and index operations with behavior distinct from SQLite |
| SQL Server | Column and index changes with dedicated syntax for defaults, included columns, and filtered indexes |
| Oracle / Dameng and similar | Oracle-style column, comment, and index DDL; irrelevant integer-length controls are disabled |
| ClickHouse / Manticore / InfluxDB and others | Only the verified implemented subset is enabled |
| JDBC/Agent | Maps through a recognized dialect and stays read-only when the dialect cannot be identified reliably |

Do not assume that every DDL feature is editable because a database can connect. Use [Database Support](/en/docs/databases) and the actual editor controls as the current source of truth.

## Concurrency and Recovery

- Drafts are based on metadata read when the editor opened and do not merge external schema changes automatically
- If execution fails, earlier statements may already have succeeded
- Atomicity of SQLite rebuilds and multi-statement DDL depends on database and driver behavior
- Refresh reloads structure and may require discarding an unsaved draft
- Read-only connections block save, and production writes require explicit confirmation every time

## Recommendations

- Use the editor for focused, single-table changes
- Put copied DDL into version control and review for larger migrations
- Use [Schema Diff](/en/docs/schema-diff) to align environments
- Use [Database Export](/en/docs/database-export) or [Scheduled Database Backups](/en/docs/database-backup) before risky changes
- Combine [Field Lineage](/en/docs/field-lineage) with application-code search before changing important columns

<Cards>
  <Card title="Schema diff" href="/en/docs/schema-diff">
    Compare environments and generate deployment scripts.
  </Card>
  <Card title="Field lineage" href="/en/docs/field-lineage">
    Inspect relationships from foreign keys, views, and query history.
  </Card>
  <Card title="Production safety" href="/en/docs/production-safety">
    Configure read-only connections and production DDL confirmation.
  </Card>
</Cards>