This is very cool. Reminds me of my days 13 years ago using dot to draw complex planaarized graph diagrams before switching to physics / springs models, graph embeddings, and other cool things.
I hope you don't mind? If you don't want ur code there let me know and I'll sadly but obediently take it down and just link to it from someplace on there I can readily find. :)
Likewise, the niche pressure for me came from SQLite being agnostic to a canonical form for SQL `.schema`. I did not need to get into parsing every flavor.
A place I worked at during the dot-com era had a large format printer[0] and the DBAs would occasionally print database schema diagram posters that they would hang on the walls. It was amazingly useful, especially as we staffed up and had a lot of new employees.
@thristian - can you specify a paper size?
[0] That once the marketing department found out about, was always out of ink.
So far as I can tell, GraphViz does not allow you to specify a paper size. However, if you render to SVG, you can open the result in Inkscape and rearrange things fairly easily. That's not quite as convenient as having it done automatically, but GraphViz can struggle with laying out a complex schema even when assuming infinite space - some amount of hand-tweaking is going to be necessary regardless.
1. Takes in a .dot file
2. Presents a simple UI for selecting which tables/relationships you want in the final diagram
3. Lets you highlight a table and add all directly related tables to the selected tables
4. Lets you select two tables and adds the tables for the shortest route between the tables
5. Lets you assign colors to tables/relationships for the final diagram
6. Optionally shows only key fields in the final diagram
7. Generates the necessary graph source and copies it to the clipboard, and loads either of two GraphViz pages to let you paste the source and see the graph.
If that would be of interest to anyone I'd be happy to post it.
Tried it on SQLite's own Fossil repo, which is a kind of SQLite db too.
The resulting diagram shows no relationship arrows.
Turns out the Fossil's schema uses REFERENCES clause with a table name only; I guess, this points to table's primary key by default. Apparently, the diagram generator requires explicit column names.
Huh. The syntax diagram in the documentation[1] suggests this is possible, but the documentation on foreign keys[2] does not mention that syntax, or how it's interpreted.
Thanks for the idea! I have a repo that (ab)uses Gitlab CI to periodically produce an SQLite database from a bunch of other data sources and this is a great addition to the README
This seems very clever. I’ve enjoyed abusing SQL, too. And note that abuse is the developer’s term for how what he’s doing in sqlite-schema-diagram.sql. I’m not trying to be insulting. I actually do like it.
What I like here is the "unix style do one thing" part of here's a simple ("simple") SQL script that pumps into GraphViz which does all of the heavy lifting.
I remember writing a script for doing this, more than 10 years ago. I haven't used it much, and not for many years.
The problem is that a fully automatic schema is only readable for very small databases. So small that very soon you can keep the structure in your head. For larger databases, the automatic schema will be awful. Even with just 20 tables, graphviz (dot | neato) will make a mess when some tables are referenced everywhere (think of `created_by` and `updated_by` pointing to `user_id`).
When I need a map of a large database, I usually create a few specialized diagrams with dbeaver, then combine them into a PDF file. Each diagram is a careful selection of tables.
You might try https://schemaspy.org/ - it generates a website with ER diagrams that only go one or two relationships out, but they have clickable table names to get to the next diagram
You can do this a little bit easier using SQLPage [1], without GraphViz, and you'll get an always up to date schema:
select 'table' as component, 'Foreign keys' as markdown;
select *, (
select
group_concat(
printf('[%s.%s](?table=%s)', fk."table",fk."to",fk."table"),
', '
)
from pragma_foreign_key_list($table) fk
where col.name = fk."from"
) as "Foreign keys"
from pragma_table_info($table) col;
I don't see how this is in any way comparable - it looks like it'd just produces a table rather than a diagram? You can indeed do that too with a single sqlite query as well if it's not the diagram you want.
Nor how running some other tool that runs a web service qualifies as "easier" than running a query using sqlite itself, and a command line tool that's trivially scriptable.
I've used this in the past and is one of my first ways of approaching a new codebase. It's great at loading a schema and letting me lay out the tables. I'll sometimes make many different subset diagrams. I hacked it a bit for working with MySQL schema and inferring 'foreign keys' by naming convention as they are often not enforced by the db schema.
Such an awesome find, I'm thinking of sticking this to my CI Pipeline now! :D
I use SQLite for a gameserver, having 3 different databases for different stuff. And this would be a lifesaver for others working on anything requiring the main database which has a lot of relations, thanks to normalizing it and having a lot of different but related data.
Thank you for this!
Years ago I wrote something similar for PostgreSQL. Unlike SQLite, it supports[1] the much richer "information_schema" database schema that's defined by the SQL standard. As long as you can figure out how it represents tables, columns, and primary and foreign keys, it shouldn't be too difficult to adapt this SQL query to fit. After all, reshaping relational data to extract the information you need is what SQL is for.
My project pdot^1 has a full-ERD mode but it's honestly less useful than the semi-interactive/contextual mode of navigating schema subgraphs in a database of any size. pdot can output mermaid and render other graphs too, like trigger cascades and grant inheritance.
> Lots of database management tools include some kind of schema diagram view,
either automatically generated
or manually editable so you can get the layout just right.
But it's usually part of a much bigger suite of tools,
and sometimes I don't want to install a tool,
I just want to get a basic overview quickly.
An old colleague of mine created an interactive web app that does this. We use it internally and I find it super useful. Supports SQLite, among others: https://azimutt.app/
I did something related to this https://github.com/wallymathieu/mejram
Main reason I did it was that I've worked on some old databases that do not have a nice normalised schema. Some of the foreign keys have been missing. Using dot-render can give you nicer graphs compared to some of the built in tools like SQL Server Management Studio.
Cool, I recently made a similar tool for generating diagrams like that for SQLalchemy data models. Can definitely be useful for understanding a complex schema.
[+] [-] thristian|1 year ago|reply
[+] [-] alexvoda|1 year ago|reply
[+] [-] keepamovin|1 year ago|reply
Nice to see a really good use for dot.
I created a fork on GitHub as a fork there'll be easier for me to come back to, find, organize and use (and may be for others too): https://github.com/o0101/sqlite-schema-diagram
I hope you don't mind? If you don't want ur code there let me know and I'll sadly but obediently take it down and just link to it from someplace on there I can readily find. :)
[+] [-] meitham|1 year ago|reply
[+] [-] tejtm|1 year ago|reply
https://github.com/TomConlin/SQLiteViz
[+] [-] ncruces|1 year ago|reply
I just mirrored it myself to keep tabs on it, because otherwise I'll forget it.
Very interesting approach.
[+] [-] NortySpock|1 year ago|reply
Have you considered outputting to a MermaidJS format?
https://mermaid.js.org/syntax/entityRelationshipDiagram.html
[+] [-] _ache_|1 year ago|reply
[+] [-] chiph|1 year ago|reply
@thristian - can you specify a paper size?
[0] That once the marketing department found out about, was always out of ink.
[+] [-] thristian|1 year ago|reply
[+] [-] gcanyon|1 year ago|reply
1. Takes in a .dot file 2. Presents a simple UI for selecting which tables/relationships you want in the final diagram 3. Lets you highlight a table and add all directly related tables to the selected tables 4. Lets you select two tables and adds the tables for the shortest route between the tables 5. Lets you assign colors to tables/relationships for the final diagram 6. Optionally shows only key fields in the final diagram 7. Generates the necessary graph source and copies it to the clipboard, and loads either of two GraphViz pages to let you paste the source and see the graph.
If that would be of interest to anyone I'd be happy to post it.
[+] [-] codetrotter|1 year ago|reply
[+] [-] mrbuttons454|1 year ago|reply
[+] [-] zoomablemind|1 year ago|reply
The resulting diagram shows no relationship arrows.
Turns out the Fossil's schema uses REFERENCES clause with a table name only; I guess, this points to table's primary key by default. Apparently, the diagram generator requires explicit column names.
[+] [-] thristian|1 year ago|reply
I think I can fix this.
[1]: https://sqlite.org/syntax/foreign-key-clause.html
[2]: https://sqlite.org/foreignkeys.html
[+] [-] thristian|1 year ago|reply
[+] [-] littlecranky67|1 year ago|reply
[+] [-] franga2000|1 year ago|reply
[+] [-] gchaincl|1 year ago|reply
[+] [-] andrewl|1 year ago|reply
[+] [-] whartung|1 year ago|reply
[+] [-] idoubtit|1 year ago|reply
The problem is that a fully automatic schema is only readable for very small databases. So small that very soon you can keep the structure in your head. For larger databases, the automatic schema will be awful. Even with just 20 tables, graphviz (dot | neato) will make a mess when some tables are referenced everywhere (think of `created_by` and `updated_by` pointing to `user_id`).
When I need a map of a large database, I usually create a few specialized diagrams with dbeaver, then combine them into a PDF file. Each diagram is a careful selection of tables.
[+] [-] olejorgenb|1 year ago|reply
[+] [-] bbkane|1 year ago|reply
[+] [-] alexvoda|1 year ago|reply
I find that almost all layout algorithms for database diagrams are rather poor.
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] lovasoa|1 year ago|reply
[+] [-] vidarh|1 year ago|reply
Nor how running some other tool that runs a web service qualifies as "easier" than running a query using sqlite itself, and a command line tool that's trivially scriptable.
[+] [-] pjmlp|1 year ago|reply
[+] [-] bbkane|1 year ago|reply
[+] [-] tedivm|1 year ago|reply
https://github.com/tedivm/paracelsus
[+] [-] mingodad|1 year ago|reply
WWW SQL Designer, your online SQL diagramming tool
[+] [-] karmakaze|1 year ago|reply
[+] [-] jll29|1 year ago|reply
However, SQLite3 on the Mac gave me:
Somewhere it is written that pragma_table_list was only made available as of 3.16, but I am actually using Anyone seen this?[+] [-] KAKAN|1 year ago|reply
I use SQLite for a gameserver, having 3 different databases for different stuff. And this would be a lifesaver for others working on anything requiring the main database which has a lot of relations, thanks to normalizing it and having a lot of different but related data. Thank you for this!
[+] [-] abi|1 year ago|reply
[+] [-] thristian|1 year ago|reply
[1]: https://www.postgresql.org/docs/current/information-schema.h...
[+] [-] ccakes|1 year ago|reply
Covers a lot of different platforms incl Postgres
[1] https://github.com/k1LoW/tbls
[+] [-] Vuizur|1 year ago|reply
[+] [-] dmfay|1 year ago|reply
^1 https://gitlab.com/dmfay/pdot
[+] [-] willlma|1 year ago|reply
An old colleague of mine created an interactive web app that does this. We use it internally and I find it super useful. Supports SQLite, among others: https://azimutt.app/
[+] [-] irreducible|1 year ago|reply
[+] [-] wallymathieu|1 year ago|reply
[+] [-] eigenvalue|1 year ago|reply