Show HN: Online database diagram editor(github.com)
github.com
Show HN: Online database diagram editor
https://github.com/drawdb-io/drawdb
70 comments
Are there any advantages that could come from encouraging a tool like this to emit both SQL and strongly-typed classes representing the data in say TypeScript and C#?
If C# alone is enough then this might be up your alley: https://learn.microsoft.com/en-us/ef/ef6/modeling/designer/w...
I like this. Definitely going on the backlog. This can be very useful.
Look at something like typewriter. It’s abandoned, but it does exactly this
Having spent fair amount of time on inf.architectural position, I’d really love these tools to also adapt some sort of markup. Sequencediagram.org being perfect example (and others alike) where it takes seconds to put a diagram that otherwise takes hours to prepare. Sadly I know of no standard and lightweight markup for E/R modelling…
Mermaid is good for flowcharts, but we still lack reasonably good one for BPMN and enterprise diagrams. (BPMN.io is great but lacks its own lang)
Mermaid is good for flowcharts, but we still lack reasonably good one for BPMN and enterprise diagrams. (BPMN.io is great but lacks its own lang)
DBML (https://dbml.dbdiagram.io/docs/) is the only thing I've seen in this space.
I have found that diagrams tend not to be worth their effort for data models and ERDs.
I spend far too much time either:
- working in a visual designer that slows me down
Or
- fighting the layout engine of a markup language and image compiler with lots of directives to try to get the diagram to lay out anywhere close to reasonably.
The most valuable information, to me, is the table schema and the collection of relationships. Toward this end, I use a markdown table of three columns, (Field, Type, Attributes) and a code block with my own shorthand per below:
Diffs are incredibly readable.
If I need to make pictures for someone else, I iterate design in a markdown file and then once it's good I will spend the time required to make a picture based off the text.
I must admit, I start to question why the pictures are necessary.
I spend far too much time either:
- working in a visual designer that slows me down
Or
- fighting the layout engine of a markup language and image compiler with lots of directives to try to get the diagram to lay out anywhere close to reasonably.
The most valuable information, to me, is the table schema and the collection of relationships. Toward this end, I use a markdown table of three columns, (Field, Type, Attributes) and a code block with my own shorthand per below:
Table[field] -1:N- Table2[field2]
Detail[HeaderId] -N:1- Header[Id]
Diffs are incredibly readable.
If I need to make pictures for someone else, I iterate design in a markdown file and then once it's good I will spend the time required to make a picture based off the text.
I must admit, I start to question why the pictures are necessary.
The pictures are necessary when:
1) you do a brainstorming. doing it the visual way is much slower than the markup way. personally done it dozens if not hundreds of times with seq.diagrams. actually started donating to this guy who created sequencediagram.org, he saved me hours
2) you need to communicate chunks of the design with non-technical personnel such as business analysts and folks who have no clue about normal forms, outer joins, relational or hybrid designs, etc. they understand much better with visual assistance, which is in essence - suggestopedic approach (https://en.wikipedia.org/wiki/Suggestopedia). and you know what - they never admit their lack of fundamental knowledge, which is even worse than not explaining the matter at all. bpmn and seq.diagrams work very well here, and of course - all 1910s flowchars should be forbidden.
3) when there's a large volume of intertwined entities. you just can't convince me that a graph is better represented as series of relational-algebra-alike texts, and not a planar image of it. try to imagine what the Northwind educational DB looks like as text ... and how you teach/explain to s.o. to walk it.
https://support.microsoft.com/en-us/office/northwind-databas...
1) you do a brainstorming. doing it the visual way is much slower than the markup way. personally done it dozens if not hundreds of times with seq.diagrams. actually started donating to this guy who created sequencediagram.org, he saved me hours
2) you need to communicate chunks of the design with non-technical personnel such as business analysts and folks who have no clue about normal forms, outer joins, relational or hybrid designs, etc. they understand much better with visual assistance, which is in essence - suggestopedic approach (https://en.wikipedia.org/wiki/Suggestopedia). and you know what - they never admit their lack of fundamental knowledge, which is even worse than not explaining the matter at all. bpmn and seq.diagrams work very well here, and of course - all 1910s flowchars should be forbidden.
3) when there's a large volume of intertwined entities. you just can't convince me that a graph is better represented as series of relational-algebra-alike texts, and not a planar image of it. try to imagine what the Northwind educational DB looks like as text ... and how you teach/explain to s.o. to walk it.
https://support.microsoft.com/en-us/office/northwind-databas...
> I start to question why the pictures are necessary
I think I agree. My habit is to keep DDL in version control, one file per database object. If I'm interested in a table, column, or its relationships, I can grep for names, look at the files and see the datatypes, foreign keys, etc.
I can also by grepping find any stored procedure or function that references a table or column because the code for those is in version control also.
I've tried diagrams and while they are convenient at a fairly high level they can't really show you everything and become unweildy if they try. I've found them of such limited benefit that I just work with text/code. I might make a simple diagram if I have to present/talk about a change.
I think I agree. My habit is to keep DDL in version control, one file per database object. If I'm interested in a table, column, or its relationships, I can grep for names, look at the files and see the datatypes, foreign keys, etc.
I can also by grepping find any stored procedure or function that references a table or column because the code for those is in version control also.
I've tried diagrams and while they are convenient at a fairly high level they can't really show you everything and become unweildy if they try. I've found them of such limited benefit that I just work with text/code. I might make a simple diagram if I have to present/talk about a change.
Yeah, the developer experience (DevEx) around diagrams is still really poor, despite some sterling efforts by folks behind Mermaid, PlantUML, D2, etc etc.
I want something that will use (text based, tree-sitter diffable, and git stored) architecture diagrams as its source of truth. Then compare those diagrams with actual code, and give us meaningful/useful divergence metrics. And from the source of truth, apply style transforms to display in different ways. D2 can do something like that last bit, with its different layout engines.
It feels like we already have the information available: we have (terraform) code that produces infrastructure, and (nodejs) code that produces applications. So how can take that structural information and turn it into something useful? I kind of like the idea of a ML model that gives you some standard views of your diagrams, then asks you which bits are useful, and which bits you want to hide/discard from the final output. Going back and forth with that a bit would produce a JSON file that tells the transform engine what to display. I don't know if an LLM can be prompted to do something like that, but a model-assisted workflow might be useful.
I also want to be able to compare before and after architectural decisions. Or compare the infrastructure and application patterns against industry best practices. Plus being able to automatically spit out updated, accurate diagrams for leadership would be great.
I want something that will use (text based, tree-sitter diffable, and git stored) architecture diagrams as its source of truth. Then compare those diagrams with actual code, and give us meaningful/useful divergence metrics. And from the source of truth, apply style transforms to display in different ways. D2 can do something like that last bit, with its different layout engines.
It feels like we already have the information available: we have (terraform) code that produces infrastructure, and (nodejs) code that produces applications. So how can take that structural information and turn it into something useful? I kind of like the idea of a ML model that gives you some standard views of your diagrams, then asks you which bits are useful, and which bits you want to hide/discard from the final output. Going back and forth with that a bit would produce a JSON file that tells the transform engine what to display. I don't know if an LLM can be prompted to do something like that, but a model-assisted workflow might be useful.
I also want to be able to compare before and after architectural decisions. Or compare the infrastructure and application patterns against industry best practices. Plus being able to automatically spit out updated, accurate diagrams for leadership would be great.
Mermaid can also be used for enterprise relationship diagrams: https://mermaid.js.org/syntax/entityRelationshipDiagram.html
What about plantuml - covers a fair bit of ground!
[deleted]
Fantastic. I was literally just looking for something like this. I'm using it now.
One thing that may be me getting my brain reversed, but when you set the "cardinality" of a relationship the "1" and "n" markings on the connecting line seem to be reversed?
One thing that may be me getting my brain reversed, but when you set the "cardinality" of a relationship the "1" and "n" markings on the connecting line seem to be reversed?
Thanks for the feedback! The "1" and "n" labels are assigned first to the foreign key then to the primary key, e.g. if you pick "Many to one" the FK side will be "n" and the PK will be "1". Let me know if you find this unintuitive or if I didn't get the question right.
Got it, and that makes sense. Thank you. I couldn't even figure out why I was confused, but then looking at the interface, I think I may have been mixing up the order fields are noted, vs cardinality.
https://ibb.co/gWS558v
https://ibb.co/gWS558v
Looks very nice! A few things I'd like to see to make it more useful:
- Let me pick a database when I start so the data types are restricted to that particular database. This can help down the line with other quirks and particularities of each db.
- I'd love to be able to use this and convert it to a model for my ORM (I'm currently using Prisma, but depending on your vision this could expand to other languages and ORMs such as, for example, Django). This would be helpful because I'd be able to jump from design to implementation without rewriting everything as models in my ORM.
- The nodes to establish relationships are difficult to click, and several times I ended up dragging the table instead. Consider making them easier to grab.
- If I delete a property from the table (in the grid) there's no quick way to undo. A toast message with an undo link would be helpful.
- The "delete diagram" option didn't ask me for confirmation and even if I saved my diagram before, it's gone. And this option is dangerously close to "Rename"!
- Let me pick a database when I start so the data types are restricted to that particular database. This can help down the line with other quirks and particularities of each db.
- I'd love to be able to use this and convert it to a model for my ORM (I'm currently using Prisma, but depending on your vision this could expand to other languages and ORMs such as, for example, Django). This would be helpful because I'd be able to jump from design to implementation without rewriting everything as models in my ORM.
- The nodes to establish relationships are difficult to click, and several times I ended up dragging the table instead. Consider making them easier to grab.
- If I delete a property from the table (in the grid) there's no quick way to undo. A toast message with an undo link would be helpful.
- The "delete diagram" option didn't ask me for confirmation and even if I saved my diagram before, it's gone. And this option is dangerously close to "Rename"!
Looks real nice!
Clean for sure.
First feedback I have is, when you click "Settings" > "Flush Storage" there is no "Hey this button will delete everything you have been working on are you sure you want to do this?" type message to confirm if someone wants to actually flush the storage.
I was about 6 or 7 tables deep messing around with it and was looking at settings and kind of absent mindedly clicked that without thinking and everything was gone :D
Clean for sure.
First feedback I have is, when you click "Settings" > "Flush Storage" there is no "Hey this button will delete everything you have been working on are you sure you want to do this?" type message to confirm if someone wants to actually flush the storage.
I was about 6 or 7 tables deep messing around with it and was looking at settings and kind of absent mindedly clicked that without thinking and everything was gone :D
Oh god i'm sorry about that. Lol funny enough i mentioned it in a reddit thread today that i need to add a warning
Lol no worries. It was pure "I don't know what I expected" for the succeeding 2 seconds.
Other feedback is that it would be nice to be able to set it to say "I want to design a database in PostgreSQL" and have the available datatypes match that. So I can specify postgres specific things like time with timezone, money, point (for geo data) etc.
How do you prefer feedback? Issues in the GH repo?
Other feedback is that it would be nice to be able to set it to say "I want to design a database in PostgreSQL" and have the available datatypes match that. So I can specify postgres specific things like time with timezone, money, point (for geo data) etc.
How do you prefer feedback? Issues in the GH repo?
I tried to have the diagrams be independent of the DBMS that's why types that are not supported in one DBMS get mapped to their closest match in another. For example SET gets mapped to an array of ENUM values in Postgres. So money, point, etc. can be easily added and mapped.
As for the feedback, thank you so much, I really appreciate it.
You can leave it anywhere you find convenient but I think GH would be ideal. It would easier to reference and maybe the community can get involved too :)
As for the feedback, thank you so much, I really appreciate it.
You can leave it anywhere you find convenient but I think GH would be ideal. It would easier to reference and maybe the community can get involved too :)
This looks great! However, a pet peeve of mine that I always share with my students is that ER diagrams do not have foreign keys. ER diagrams represent relationships with a diamond connected by lines to the related entities. It looks like what this is producing is not really an ER diagram.
The big diamonds are specifically the Chen notation of ER diagrams. Which is popular in academia because that's how Professor Chen first described ER models, but seems pretty unpopular everywhere else because it's not that readable, especially as models get larger. Most people who have to actually use ER diagrams seem to use some variation of the UML notation. And even though it doesn't seem to have a name, OPs version is a pretty straightforward (and imho more intuitive) extension of the UML notation (forbidding N-N relationships and adding the relationship name as a foreign key to the table instead of writing it on the arrow). It's also hardly the first time I've seen it, we just need someone to publish a book that gives it a catchy name.
If we want people to actually use ER diagrams, treating the original version from 50 years ago as the only valid way to write them doesn't seem useful. Both science and engineering are about iterative improvement after all.
If we want people to actually use ER diagrams, treating the original version from 50 years ago as the only valid way to write them doesn't seem useful. Both science and engineering are about iterative improvement after all.
I'm not saying the diagrams the OP is using aren't useful, but I would argue that they are not ER diagrams.
At first I thought this was drawio: https://www.drawio.com/ with which you can generate a schema diagram from SQL. Is this the other way around.
It's meant to support both ways, plus additional finer control over the tables, custom types, and error checking
[deleted]
What's up with projects using "-io"/".io" in their name but not actually using a .io domain?
drawio.com brands itself as "draw.io" but uses .com.
OP, why is it "drawdb-io"?
Cool project btw :)
drawio.com brands itself as "draw.io" but uses .com.
OP, why is it "drawdb-io"?
Cool project btw :)
This looks great.
Would be even better if it lived in VSCode, auto-syncing with my DDL files...
Would be even better if it lived in VSCode, auto-syncing with my DDL files...
Honestly, what I'm looking for is a tool that generates the docs and diagrams for a database from the database schema itself and lays it out cleanly. So far I've found tools that will try to generate a diagram naively even if there are a hundred tables, and I've found tools that make you recreate your structure twice: once in DDL and the second time in docs/diagramming.
I want Javadoc with scoped diagrams for relational databases.
I want Javadoc with scoped diagrams for relational databases.
Maybe you can use schemaspy? https://schemaspy.org/
It's been a while since I looked at SchemaSpy. It has improved a lot since I last looked. Thanks for the recommendation! I wish the layout were a little more polished, but the content/functionality is definitely there.
As long as the relationships are also defined in the DDL, the DDL is the only thing that is needed. You can use an automated diagrammer such as the one in https://visualdb.com/ It shows tables and relationships graphically, and you can click on a table to see its columns and data types.
Then you should probably push adoption of markdown for javadoc (1). That and mermaid extension should be a good candidate. Or just use javadoc with an additional md plugin.
1 - https://mail.openjdk.org/pipermail/javadoc-dev/2023-January/...
1 - https://mail.openjdk.org/pipermail/javadoc-dev/2023-January/...
Javadoc is for Java code. I want something that generates documentation for relational databases, not Java. Hence: Javadoc for relational databases.
Cool project. Your website is much more detailed than your Github so I'd like to share this for visibility: https://drawdb.vercel.app/
Any updates on PostgreSQL import support?
Any updates on PostgreSQL import support?
thanks! yep it's definitely coming. can't promise anything for the coming week but i'll try my best to have it out asap
For tools like these, I need the ability to save locally to my own device and not have anything saved/sent to the cloud. draw.io is the best example of this.
Nothing gets sent to the cloud, everything is in your browser in IndexedDB. If you go to Inspect>Application>IndexedDB in the storage section you'll see exactly what gets saved and where
You can use the Export as DrawDB and Import Diagram options to save and load locally.
yep, this or as json
Nothing beats dbdiagram [0]!
[0]: https://dbdiagram.io/
[0]: https://dbdiagram.io/
It requires login to export diagrams.
https://databasediagram.com/app
and
https://app.quickdatabasediagrams.com/
are better alternatives, at least in that these won't ask login.
https://databasediagram.com/app
and
https://app.quickdatabasediagrams.com/
are better alternatives, at least in that these won't ask login.
Not open source like OP's
The underlying markup language is, and there's a number of open source renderers
https://github.com/holistics/dbml
https://github.com/holistics/dbml
Oh nice that you mention that. Didn't find an equivalent open-source web-based diagrammer. I found:
- ISC license, renders to SVG: https://github.com/softwaretechnik-berlin/dbml-renderer
- DBML community contributions: https://dbml.dbdiagram.io/home/#who-s-behind-dbml
- ISC license, renders to SVG: https://github.com/softwaretechnik-berlin/dbml-renderer
- DBML community contributions: https://dbml.dbdiagram.io/home/#who-s-behind-dbml
Dbdiagram is pretty op. Actually my initial prototype was very similar to it
The feature that I miss in 99% of the tools is this one [0]!
[0]: https://dbdiagram.io/docs/release-notes/2024-03-adjustable-r...
[0]: https://dbdiagram.io/docs/release-notes/2024-03-adjustable-r...
What was your motivation for making a different tool?
At first it was mostly for myself just as a learning experience and a project that would go on my resume. I wasn't even planning to open source it until people started expressing interest in it. Now that it's out and there's feedback we can cater to more specific use cases
Does this look at my database for me or is it for ideation?
Oh, this is nice!
If you want to check out the app you can go to https://drawdb.vercel.app/ .
Thank you:)