SqlDBM + Teradata

MULTISET, FALLBACK, journaling, MAP, compression, the primary index. The properties that decide how Teradata behaves are fields in the model, not comments in a script.

Book a Demo

THE PROBLEM

Most tools turn Teradata into generic SQL

A modeling tool that treats every platform the same gives you tables, columns and keys, and quietly drops everything else. But on Teradata the everything else is the part that matters: whether a table is SET or MULTISET, whether it falls back, how it’s journalled, which map it lands on, what compresses. Those decisions are why the system performs the way it does — and they end up living in scripts nobody models, or in the heads of the two people who remember.

The model and the database disagree. The diagram says table; production says MULTISET, FALLBACK, no primary index.
Round-tripping loses things. Import the DDL, edit the model, generate it back, and the physical properties are gone.
The knowledge isn’t written down. Why this table is journalled and that one isn’t is a decision no artefact records.

WHAT SURVIVES

A property, not a comment

SqlDBM holds Teradata’s physical properties as first-class fields on the object, not as text pasted into a description. Table type and kind, fallback, before and after journals, checksum, freespace, mergeblock ratio, datablock size, block compression, map, isolated loading, no primary index — each one is a property you set, review and forward engineer. Columns carry format, title, character set, case specific, compression and full identity options. Views, functions and procedures come with overloading parameters.

Eleven of more than thirty. Each is a property on the object, not a note somebody left in a description.

IN THE MODEL

Physical properties, in the properties panel

Table type, table kind, fallback, journaling, checksum, freespace, mergeblock ratio, datablock size, block compression, map and isolated loading are fields on the object — set them once, see them in the model, and have them generated back out with the DDL. No one has to remember which tables were special.

SqlDBM table properties panel
with the Teradata options visible

Getting your Teradata model in

1

Create a Teradata project

Choose Teradata as the project type. From that point the editor offers Teradata’s objects and properties rather than a generic set.

2

Bring in what you already have

Choose Reverse Engineering and upload your DDL script — drop the file in or paste it into the editor. SqlDBM parses the Teradata syntax, physical properties included, and diagrams the result. An Excel upload works too if your definitions already live in a spreadsheet.

3

Model it as Teradata

Set table and column properties as fields on the object — type and kind, fallback, journaling, compression, partitioning, identity — rather than as free text somebody has to interpret later.

4

Generate the DDL back out

Forward engineer create or alter scripts in Teradata syntax, and push them to your repository over any of the git connections.

THE PAYOFF

What stops being tribal knowledge

The model matches production

What the diagram says about a table is what the database does, down to the physical properties.

Round trips keep their detail

Upload the DDL, change the model, generate it back — and the journaling, compression and index decisions come with it.

Decisions become reviewable

Why a table is MULTISET, or has no primary index, is a property somebody can see and question rather than a choice buried in a script.

Teradata joins the rest of the estate

The same modeling surface, review path and git connections as your cloud platforms, rather than a separate process for the system nobody else touches.