ChartDB – Free and open source, database design editor
chartdb.io
chartdb.io
Not sure what it takes for simple ER diagrams to become the norm for project documentation. In spite of so many tools being available in this space hardly anyone actually uses them in practice.
Maybe Microsoft has to make it a feature in Excel or PowerPoint for people to use it?
These diagrams need not be exhaustive but should convey the key structure and relations as per context. We can create a dozen small diagrams for the same database if needed to document the requirements and design. Whatever works and does the job of communicating and documenting.
1. MIS vs CS
Management Information Systems vs Computer Science, in general people with background in MIS are more into Databases than CS people
A person with MIS background is more likely to start with an ERD, and move to code later, CS people prefer to code first
2. UML is a disaster
Since the 90s UML is the Diagraming language and it never had a DB component (probably created by CS guys) (you adapted a Class diagram for ERD)
And UML is not code, and its hard if not impossible to code in UML
Its a lot easier to go from code to diagram and diagram to code for ERD, not the case for other types of coding
I think the rise and failure of UML played a big role in coders not diagramming
3. Code browsing tools
Code browsing tools are usually good enough for most coders, seing the structure of your code as a tree on the left pane of your code editor
A lot of developers even with multiple years of industry experience seem to start projects with code first -- as if it will be running on their PC.
Not enough systems / design thinking of how the application will run in a DEV environment (typically cloud these days) let alone production -- what the various components of that application are going to be -- and where and in form the data will be persisted.
For creating ERDs as code, tools like dbdiagram.io and eraser.io are popular options. ERWin is the original tool for UML/ERD diagrams, but it's expensive.
I'm being sincere. Maybe I should be using it. I don't see why though.
Certainly, with complex relations between various tables, having a design tool like this can help you visualize what you are doing. This in turn can help you in spotting things you might otherwise overlook.
Some of it depends on the sort of database work you do and how complex your database will be. If you only have a few simple tables with virtually no relations between them, this might indeed be overkill for you.
If you reach a level of project maturity where you don't have (or want to have) the entire db model in your head you should use it.
If you have multiple models in different systems you should use it.
If you work with other people and you want to make it easier to communicate db models you should use it.
If you want to communicate db models publicly you should use it.
If you want to plan your db models in advance you should use it.
When I say you should use it I mean the end diagrams, I don't specifically mean this tool.
I loath mentality "but the code is self explanatory!" :/
Have you ever inherited a project with 80 tables and no documentation at all, or at best a 50 page document with database schema dumps?
You can draw it all on one page as an ERD (entity relationship diagram) with the main tables and their relationships. And this diagram can be understood in minutes, not hours/days like in the case of the schema dumps.
Also you can use various ERD editors, or text-based diagramming tools, like PlatUML, MermaidJS, DBML, on the schema design stage, while keeping the diagram sources in the source control.
Another usecase is to generate a detailed ERD for the current database schema in CI, and periodically review it, to ensure it conforms to the original design, and you understanding of the current schema is correct.
1. A lot of the diagram-based modeling/visualization languages and tools are too simple, or poorly rendered, missing most of the potential value. (For example, for some product segments I knew, sold via enterprise sales, most of the offerings seemed to be developed by people who didn't use it themselves, and didn't have guidance from a domain expert.)
2. A lot of the examples people see of them are too simple, and often just plain wrong. (I was lucky to have a colleague explaining a complicated system by talking people through a rich diagram, and it was borderline epiphany. Then later I saw product managers and engineers make diagrams that were obviously incorrect/nonsensical, and otherwise weren't useful.)
3. I have a suspicion it might also sometimes involve some people having different "visual" or "spatial" thinking than others. Given a rich diagram in a familiar standardized visual language, do some people reason about it more visually than others, who are, say, reading it more like verbally, and reasoning from concepts that way?
Looking around i find most tools in this corner are either full fledged DB design tools with their own editor, but no API. The others like this and things like dbdiagram.io usually are focused online only, which is not an option for me.
Any suggestions greatly appreciated...
This caused many one-on-one meetings where we would look at the diagram, and I'd note changes to be made for next meeting.
With this, we could have made changes live during meetings, and saved many iterations.
Things like pgadmin existed, but it didn't look as friendly for non-technical folks. This might decrease some friction.
I understand why people uses them, I just don't need a tool like that.
So every tool "exports to SQL" expecting all changes in the database are reflected in the diagram. But the diagram is not the database. So we've got two jobs now.
also:
"The map is not the territory"
Diagram is a model, you always have a model, whether explicit or implicit (mental).
Your mental model can be flawed, but nobody can see it to point it out (including yourself).
A default of "show none" is probably sane for visibility, in particular if you have many tables or columns in the whole diagram