[HN Gopher] Show HN: Online database diagram editor
___________________________________________________________________
Show HN: Online database diagram editor
Hey all! I released drawDB about a month ago and now it's open
source. I hope you find it useful. If you want to check out the
app you can go to https://drawdb.vercel.app/ . Thank you:)
Author : 1ilit
Score : 274 points
Date : 2024-04-06 21:52 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ttfkam wrote:
| 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.
| zihotki wrote:
| 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/...
| ttfkam wrote:
| Javadoc is for Java code. I want something that generates
| documentation for relational databases, not Java. Hence:
| Javadoc for relational databases.
| phaza wrote:
| Maybe you can use schemaspy? https://schemaspy.org/
| ttfkam wrote:
| 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.
| breadwinner wrote:
| 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.
| yodon wrote:
| 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#?
| 1ilit wrote:
| I like this. Definitely going on the backlog. This can be very
| useful.
| Atotalnoob wrote:
| Look at something like typewriter. It's abandoned, but it
| does exactly this
| datascienced wrote:
| If C# alone is enough then this might be up your alley:
| https://learn.microsoft.com/en-us/ef/ef6/modeling/designer/w...
| nirav72 wrote:
| This is great! Any plans to containerize this?
| 1ilit wrote:
| Yep! Hopefully soon
| nikolay wrote:
| Nothing beats dbdiagram [0]!
|
| [0]: https://dbdiagram.io/
| gremlinunderway wrote:
| Not open source like OP's
| bdcravens wrote:
| The underlying markup language is, and there's a number of
| open source renderers
|
| https://github.com/holistics/dbml
| rapnie wrote:
| 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
| 1ilit wrote:
| Dbdiagram is pretty op. Actually my initial prototype was very
| similar to it
| hk__2 wrote:
| What was your motivation for making a different tool?
| 1ilit wrote:
| 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
| nikolay wrote:
| 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...
| smusamashah wrote:
| 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.
| matthasfun wrote:
| 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
| 1ilit wrote:
| 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
| matthasfun wrote:
| 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?
| 1ilit wrote:
| 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 :)
| sopooneo wrote:
| 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?
| 1ilit wrote:
| 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.
| xydac wrote:
| looks nice, wonder what would take to hook this to a database
| connection directly
| 1ilit wrote:
| Can see it happening for sure. Perhaps porting it to electron
| and taking in dbms type and host url for the connection will do
| it
| MForster wrote:
| This looks great.
|
| Would be even better if it lived in VSCode, auto-syncing with my
| DDL files...
| 1ilit wrote:
| This was in the plans when i was just starting out until i
| realized how much longer it was gonna take just to finish the
| web app. Can't say anytime soon but i'd love to make this
| happen
| beretguy wrote:
| Please do however long it takes.
| account-5 wrote:
| 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.
| 1ilit wrote:
| It's meant to support both ways, plus additional finer control
| over the tables, custom types, and error checking
| victorbjorklund wrote:
| Oh, this is nice!
| trenchgun wrote:
| Have you considered packaging this as a VSCode extension?
| beretguy wrote:
| Please do. I personally won't use it otherwise.
| larodi wrote:
| 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)
| nfm wrote:
| DBML (https://dbml.dbdiagram.io/docs/) is the only thing I've
| seen in this space.
| bastih wrote:
| What about plantuml - covers a fair bit of ground!
| greggyb wrote:
| 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:
| Table[field] -1:N- Table2[field2] Detail[HeaderId]
| -N:1- Header[Id]
|
| All text, no generated pictures. If I need to generate from
| DDL, that's pretty straightforward. But I can also mock up new
| designs at typing speed.
|
| 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.
| bloopernova wrote:
| 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.
| SoftTalker wrote:
| > 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.
| me_bx wrote:
| You might want to mention that it is a "data modelling tool"
| somewhere in the description text, as some of your target users
| will definitely use that term to search for such a solution...
| 1ilit wrote:
| thanks! will do
| jesperwe wrote:
| As soon as you add postgres SQL import this will be my daily
| driver! (I've been looking for a tool like this many times)
| 1ilit wrote:
| I'll look into it, thanks for the suggestion
| gardenhedge wrote:
| 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.
| kcartlidge wrote:
| You can use the _Export as DrawDB_ and _Import Diagram_ options
| to save and load locally.
| 1ilit wrote:
| yep, this or as json
| 1ilit wrote:
| 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
| p4bl0 wrote:
| This is awesome I was just looking for something like that. The
| ability to build the diagram from the SQL source is really cool!
| Thanks!
| 1ilit wrote:
| thank you!
| michaelmior wrote:
| 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.
| wongarsu wrote:
| 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.
| michaelmior wrote:
| I'm not saying the diagrams the OP is using aren't useful,
| but I would argue that they are not ER diagrams.
| adawg4 wrote:
| Does this look at my database for me or is it for ideation?
___________________________________________________________________
(page generated 2024-04-07 23:01 UTC)