DBML currently supports expression-based indexes, but it does not appear to support a first-class representation of computed/generated columns.
This creates a modeling gap for schemas where a derived value is part of the conceptual design, not just an implementation detail of an index. Examples include:
• SQL Server computed columns
• MySQL generated columns
• PostgreSQL generated columns
• Oracle virtual columns
At present, users seem to have two imperfect options:
1. Model the derived value as a normal column, which causes dbml2sql to generate DDL for a physical column that is not actually intended.
2. Represent the derivation only inside an expression index, which captures one use of the expression but not the existence of the conceptual derived column itself.
Neither approach cleanly represents the schema, and both require manual editing of the DDL generated by dbml2sql.
Suggestion: Add first-class support for computed/generated columns in DBML.
Example 1:
Table person {
ssn char(9) [not null]
ssn_last char(4) [computed: `RIGHT(ssn, 4)`]
}
Example 2 (adds storage semantics):
Table person {
ssn char(9) [not null]
ssn_last char(4) [computed: `RIGHT(ssn, 4)`, stored]
indexes {
(name_last, ssn_last) [name: 'IX_person_name_last_four']
}
}
Benefits
• Represents the logical schema more faithfully
• Distinguishes derived columns from ordinary stored columns
• Lets indexes refer to derived columns naturally
• Reduces reliance on notes or expression-only indexes to encode important schema meaning
• Improves portability across database engines with different generated/computed column syntax
• Reduces manual post-processing of dbml2sql output
Possible considerations
Depending on scope, it may be useful to support:
• virtual vs stored/persisted semantics
• engine-specific export mappings
• dbml syntax token so computed column names can be visually unique (assumes whole-line regex and back-referenced token)
• diagram rendering that visually distinguishes computed/generated columns
DBML currently supports expression-based indexes, but it does not appear to support a first-class representation of computed/generated columns.
This creates a modeling gap for schemas where a derived value is part of the conceptual design, not just an implementation detail of an index. Examples include:
• SQL Server computed columns
• MySQL generated columns
• PostgreSQL generated columns
• Oracle virtual columns
At present, users seem to have two imperfect options:
1. Model the derived value as a normal column, which causes
dbml2sqlto generate DDL for a physical column that is not actually intended.2. Represent the derivation only inside an expression index, which captures one use of the expression but not the existence of the conceptual derived column itself.
Neither approach cleanly represents the schema, and both require manual editing of the DDL generated by
dbml2sql.Suggestion: Add first-class support for computed/generated columns in DBML.
Example 1:
Example 2 (adds storage semantics):
Benefits
• Represents the logical schema more faithfully
• Distinguishes derived columns from ordinary stored columns
• Lets indexes refer to derived columns naturally
• Reduces reliance on notes or expression-only indexes to encode important schema meaning
• Improves portability across database engines with different generated/computed column syntax
• Reduces manual post-processing of dbml2sql output
Possible considerations
Depending on scope, it may be useful to support:
• virtual vs stored/persisted semantics
• engine-specific export mappings
• dbml syntax token so computed column names can be visually unique (assumes whole-line regex and back-referenced token)
• diagram rendering that visually distinguishes computed/generated columns