Create Tables and Fields
Most of your schema work in DBModeler happens through tables and fields. The editor combines a visual diagram with a properties panel so you can shape the schema without switching tools.
Add a table
Section titled “Add a table”Create a table from the editor and give it a clear, engine-safe identifier.
Typical first inputs are:
- table name
- optional description
After creation, the new table appears as a draggable node in the diagram.
Edit table properties
Section titled “Edit table properties”When a table is selected, the properties panel exposes core table metadata.
Depending on the engine, this can include:
- table name and description
- default schema placement
- table engine when supported by the database
- constraint-related tabs or SQL-oriented previews
Use this panel to refine the table after the first draft instead of recreating it.
Add fields
Section titled “Add fields”Fields define the real shape of the table.
For each field, DBModeler can capture:
- name
- canonical data type
- type parameters such as length or precision
- nullability
- default value
- uniqueness or primary-key-related flags
- ID generation strategy where supported by the engine
The field editor uses autocomplete backed by the catalog, so you work from logical DBModeler types instead of memorizing every engine-specific spelling.
Reorder and refine fields
Section titled “Reorder and refine fields”You can update a field after creation and reorder fields as the table evolves.
This matters for readability in both the diagram and generated SQL.
When changing an existing field, keep in mind that later migration SQL depends on the detected diff between versions, not just the current snapshot.
Use the right default ID strategy
Section titled “Use the right default ID strategy”DBModeler supports different generation strategies depending on the engine and selected type:
- identity
- auto increment
- sequence
- function-backed defaults
The available options change by engine and by type. If an engine does not support a strategy, DBModeler falls back to the strategies allowed by the catalog.
Not-null changes on existing structures
Section titled “Not-null changes on existing structures”When a field becomes non-nullable after data may already exist, DBModeler can prompt for a fill value. This is a safety measure to avoid generating migration SQL that would fail immediately on existing rows.
Practical modeling tips
Section titled “Practical modeling tips”- Start with a stable primary key strategy first.
- Use descriptions when the table name alone is too terse.
- Keep canonical types consistent across related tables so migrations stay readable.
- Create a version checkpoint before large refactors.