Open a schema that has been alive for three years and read five tables at random. One has created_at and updated_at. The next has only created_at, because it was added during a sprint when nobody was thinking about updates. A third spells it creation_date. One table keeps its foreign keys neatly under the primary key; another has them scattered wherever the ALTER statements happened to land. Every table is a fossil of the day it was designed - who designed it, what they remembered, how much of a hurry they were in.
None of these differences are decisions. Nobody chose five timestamp conventions. The schema drifted, one blank table at a time, and now every reader pays a small tax on every table: is the audit column missing, or just named differently? Is this table soft-deleted? You cannot skim a schema that keeps changing its own rules.
Conventions that live in heads do not survive
Most teams do have a convention. It lives in a wiki page titled “Database Standards”, or in the head of the engineer who wrote the first twenty tables, or in a code review comment from 2023. The problem is where it does not live: in the tool where tables are actually created.
A convention that must be remembered will be forgotten - not out of carelessness, but because designing a table is already a full-attention task. You are thinking about cardinality, about whether this relationship is really 1:N, about what uniquely identifies a row. “Also recall the house rules for audit columns” is exactly the kind of side quest that gets dropped. The blank entity is where drift begins, because blank means every designer starts from their own memory.
The fix is not a better wiki page. It is making the convention the starting point instead of a checklist item.
Templates: the house style, applied before you can forget it
Schemity lets you define entity templates and mark one as active. Every new entity starts with the fields defined in the active template - your id with its type and default, your created_at, updated_at, deleted_at, whatever your team has agreed a table minimally owes its readers. The convention stops being something you apply and becomes something you would have to actively remove.
That inversion is the whole trick. Forgetting now produces a consistent table; only a deliberate act produces an exception. And because you can define multiple templates, “house style” does not have to mean “one style” - a template for regular entities, another for append-only event tables, another for join-heavy reference data. Switch the active template when you switch the kind of table you are designing, and every new entity in a modeling session starts on convention.
For an ERD tool for software engineers, this is the same idea as a linter or a project scaffold: encode the standard once, in the tool, so humans spend their attention on the parts that are actually different about this table.
The ordering you should never have to think about
Field order sounds cosmetic until you read schemas all day. A table reads like a sentence: identity first, relationships next, the table’s own substance in the middle, bookkeeping at the end. When every table follows that shape, your eyes know where to look. When tables do not, you re-scan every one from the top.
Schemity maintains the shape for you. Add a new field and it is inserted above the timestamp fields - created_at, updated_at, deleted_at conventionally sit at the bottom, and they stay there without you shepherding them. Add a foreign key and it lands right below the primary key, or below the existing foreign keys if there are any. The sentence structure holds, insertion after insertion, and when you do want a custom order, fields reorder with drag and drop or a keyboard shortcut - the default is convention, not a cage.
Foreign keys get the naming treatment too, not just the placement. Each connection carries a foreign key naming convention - snake_case or camelCase - and every foreign key you create by dragging one entity to another is named accordingly. user_id next to orderId in the same schema is the naming version of five timestamp spellings, and it usually happens for the same reason: two people, two days, two habits. Set the convention once on the connection and the drag-and-drop gesture that creates the relationship also gets the name right.
There is a quieter benefit here for anyone who diffs their diagrams. Because Schemity is a local ERD tool storing plain JSON files in Git, consistent field placement means small, readable diffs - a new field shows up as one line in a predictable place, not a reshuffle. Convention in the editor becomes signal in the pull request.
Consistency is copied, not just configured
Sometimes the pattern you want to repeat is not the template but a table you just finished. A products table with its unique constraints, its check constraint, its carefully chosen defaults - and now you need services, which is 80% the same shape. Schemity lets you copy and paste entities and individual fields, so the second table inherits the first one’s decisions instead of your best recollection of them. Duplicate, rename inline with a double-click, adjust the parts that differ, done.
Between templates for the baseline, automatic placement for the shape, and copy-paste for the patterns in between, the schema stops depending on memory. That is really what “ERD best practices” comes down to in daily work - not a document describing consistency, but a data modeling tool where the consistent thing is also the easy thing.
Three years from now someone will open your schema and read five tables at random. Whether they can skim them - or have to decode each one - is being decided now, at the blank entity. Do not start from blank.