EditorialDiagramSoftware Engineering
Editorial Database Schema Diagram Designer — No Shadows, No Mermaid Slop
Review eight illustrative commerce tables in two four-table subsystems. Read physical table names, SQL types and key constraints, then trace foreign keys from the source column row to the referenced primary-key row.
Take it with you
Free PNG includes an EditorialDiagram watermark.
Layout Grammar & Anti-Patterns
Four rules for this diagram
- 01
Print schema.table in a TABLE header and show real SQL types alongside each column. Use fixed 24px column rows and restrained PK, FK and UQ markers.
- 02
Anchor each foreign key at the center of its source and referenced column rows. Fan two connections to the same primary-key row by ±8px.
- 03
Label every FK with its ON DELETE action. In this compact example, CASCADE and RESTRICT are action labels, not entity cardinalities.
- 04
Keep each subsystem to five tables and eight visible columns per table. Highlight one destructive FK and its target table header; split larger schemas instead of shrinking the type.
Three mistakes to avoid
- Box-to-box foreign-key edges hide which column participates and reduce a physical schema to ER.
- Missing SQL types or deletion actions remove the information a migration reviewer needs.
- A complete database dump with every index and constraint chip is unreadable at diagram scale.
Engineer vs. Executive
The two renders use the same illustrative source. Executive mode groups detail deliberately; read the captions before using an overview for a technical review.
Eight tables in two named subsystems retain SQL types, key markers and six column-anchored FKs.
Four sales tables show the order lifecycle; the complete catalog subsystem stays in Engineer mode.
When to use another diagram instead
ER Diagram
Use ER for conceptual entity relationships before deciding physical storage details.
System Architecture Diagram
Use architecture for database ownership, access paths and the surrounding services.
Architecture Delta Diagram
Use a delta to compare component topology before and after a storage migration; review column changes separately.
Questions about this diagram
Why is the eight-table example divided into Sales and Catalog?
The physical-schema reference caps each view at five tables. Sales shows customers, orders, payments and shipments; Catalog shows categories, products, warehouses and inventory. Each four-table subsystem stays reviewable while the full example retains all eight tables and six FK relationships.
Where do the foreign-key arrows attach?
Each starts at the source FK column row and arrives at the referenced PK row, using the fixed 24px row pitch. When payments and shipments both reference orders.id, their destination ports are fanned within that primary-key row rather than stacked at one point. This is the distinction from an entity-level ER connector.
Can I use the sample as an executable database migration?
No. The sample is an illustrative physical model with declared SQL types and ON DELETE actions. It does not supply executable DDL, validate against a live database or establish application data rules. Use the drawing to review your actual schema and keep migration tooling as the source of implementation truth.
Worked examples use illustrative data. Edited sources require an AI provider; cached previews are ready immediately.
Cached examples are free. Starter Pack is $9.9 once; Pro Pass is $8.9 per month. Every generation costs 10 credits, including one automatic geometry repair. Pricing