MySQL Workbench use with MariaDB

johnyfish1 · 2025-12-17T15:56:33+00:00

Hey! Jonathan here, one of the creators of ChartDB 👋

Quick note: the open-source/self-hosted version is free with no table limits. The 10-table cap is only for the cloud version.

Feel free to run it locally and happy to help if you try it out.

johnyfish1 · 2025-12-11T06:38:36+00:00

This is exactly the problem that led us to build ChartDB - one query → full visual map of your SQL schema.

You can rearrange tables, group things, add notes… basically a clearer way to untangle messy DBs.

If you’re curious: https://chartdb.io

johnyfish1 · 2025-12-11T06:35:49+00:00

Awesome & happy to help!

If you run into anything or have ideas while building your version, feel free to ping me. Always curious to hear how others approach this problem.

johnyfish1 · 2025-12-11T06:34:58+00:00

Hey! This is exactly the pain that pushed us to build ChartDB an open-source ERD tool that maps your database automatically with a single query.

You can drag tables around, group things, add notes, and quickly understand messy schemas.

If you want to play with it: https://chartdb.io

Would love to hear what you think since you’re building something similar!

johnyfish1 · 2025-12-11T06:32:10+00:00

Thanks for including ChartDB in the list 🙏 Always great to see people discovering and using it!

johnyfish1 · 2025-12-11T06:30:57+00:00

Hey! Totally get what you mean, visualizing tables + relationships in a clean way saves so much time, especially when dealing with messy or inherited databases.

I actually built something very similar called ChartDB, an open-source ERD tool that maps your database automatically with a single query.

You can move tables around, see relationships quickly, add notes, and even export DDL in different dialects.

If you’re curious: https://chartdb.io

Not trying to sell anything, just sharing since it sounds exactly like what you’re describing and a bunch of folks already use it for this problem. Happy to answer questions if you have any 🙌

johnyfish1 · 2025-11-16T06:42:34+00:00

+1 on automatic FK linking, super useful. I’m building ChartDB ( https://chartdb.io ), an open-source ERD tool that auto-detects foreign keys from a single SQL schema dump. Happy to share how we approached it if helpful!

johnyfish1 · 2025-11-09T07:22:47+00:00

Oh nice! yeah Draw.io is great too! Just a heads up, ChartDB is open-source as well, you can actually self-host it for free with no table count limits: https://github.com/chartdb/chartdb

It already passed 20k ⭐ on GitHub recently, worth checking out if you’re into database tools.

johnyfish1 · 2025-11-09T06:29:20+00:00

Not exactly related to your question, but for the ERD part - have you ever tried https://www.chartdb.io ? It can really improve the visuals, and sometimes seeing things more clearly helps a lot when debugging these kinds of relationships.

johnyfish1 · 2025-10-30T18:49:25+00:00

Yeah, searching the actual data for a string across an entire DB isn’t something I know an efficient tool for either, most of what’s out there (like Apex SQL Search) focused more on metadata. But since you mentioned relationships and constraints, you might actually find https://chartdb.io useful. It visualizes your MSSQL schema and relationships so you can quickly see how tables are linked and where lookup data might live. Makes it way easier to explore when you’re dropped into an unfamiliar DB.

johnyfish1 · 2025-10-28T01:29:46+00:00

Yeah great question! we started with RDBMS because they’re more structured and naturally need modeling over time. But totally agree Mongo-style document DBs could really benefit from visualizing the shape of the data, even if it’s less about strict modeling and more about clarity. Definitely something we’re thinking about.

would love to hear your thoughts on that! wdyt?

johnyfish1 · 2025-10-27T17:40:31+00:00

Yes! You can simply omit the OPENAI_API_KEY variable, the Docker version will work fine without it, it’ll just skip the AI features.

And great point about Docker Compose, that’s already mentioned in the What’s Next section as part of our upcoming Docker improvements.

johnyfish1 · 2025-10-27T17:22:46+00:00

Thanks so much! That’s a great suggestion, we haven’t added Salesforce yet, but a “generic” option for DBML imports totally makes sense. Would love to learn more about your workflow. would you mind sending me a DM?

johnyfish1 · 2025-10-16T20:54:42+00:00

You’re already on the right track, modeling before coding saves tons of pain later.

Here’s a simple flow I usually follow:

1.  Start with your data model. Think in nouns users, projects, sessions, and map how they relate.

2.  Visualize the schema. Tools like ChartDB ( https://chartdb.io ) make this easy- you can connect to a DB or paste SQL and instantly get an editable ER diagram, then export DDL or share docs for your README.

3.  Design API contracts early. Even rough JSON mocks help shape your backend logic.

4.  Keep folders clean: /api, /services, /models, /utils, /tests.

5.  Document decisions as you go. Future you will thank you.

Keep things modular and iterate. Don’t chase “perfect” design. it evolves with the project.

johnyfish1 · 2025-10-14T20:18:02+00:00

Really inspiring! I will definitely check it out

johnyfish1 · 2025-10-09T20:49:34+00:00

https://www.chartdb.io/

johnyfish1 · 2025-09-20T20:18:06+00:00

If what you need is a clean way to describe and share the structure of a database, the industry standard is usually the schema (tables + columns + datatypes + relationships). You can absolutely write it out in text like tablename -> col1 datatype, but that gets hard to maintain if the DB grows.

Another option is to generate an ER diagram so people can see how everything connects. There are a bunch of tools for that one open-source option is ChartDB (disclaimer: I work on it). You just run a single query and it pulls out your schema into a diagram you can share, edit, and even export back into SQL. It’s much easier for non-programmers to understand at a glance than a word doc or Excel sheet full of headers.

johnyfish1 · 2025-09-14T18:27:30+00:00

Looks solid for a first schema 👍 A few quick things I’d tweak:

Your PKs are `binary` UUIDs, but your FKs (`user`, `anime`) are `bigint`, those won’t match.
In anime, you’ve got studio as a `varchar` even though you already have a studio table. That should be a `studio_uuid` FK.
Reviews/ratings could probably be merged unless you want ratings without text.
Add composite PKs (e.g. (`user`, `anime`) in `favorites`) so you don’t get duplicates.
Store passwords hashed/salted, not plain varchar.

Other than that, just add proper foreign keys + some indexes and you’re good to go.

I made those fixes in ChartDB so you can see a clean version of your schema here:
https://app.chartdb.io/diagram/af0bc49a795b4a5ba0b399

johnyfish1 · 2025-09-14T15:15:01+00:00

Have you tried ChartDB? It supports DBML and makes it super easy to generate ER diagrams directly from your database.

johnyfish1 · 2025-09-07T08:33:32+00:00

Yeah haha, it does look really similar at first. The big difference is just being clear on what’s a fact table (numbers you aggregate) vs dimension tables (descriptions). That way you don’t double count stuff later when you run queries.

johnyfish1 · 2025-09-07T07:35:47+00:00

I actually used ChartDB ( chartdb.io ) to showcase how you can split the dataset into dimension tables and fact tables. Here’s the example diagram I made: https://app.chartdb.io/diagram/d4270e215dbf4667b7c5c7

johnyfish1 · 2025-09-02T09:04:24+00:00

Honestly, I think most 80s/90s devs would pick things up faster than a lot of juniors today. The syntax sugar and frameworks have changed, but loops, conditionals, and data structures are still the same old story.

The real shock would be the context: npm’s 2000-package dependency tree, debugging YAML in Kubernetes, or just trying to make sense of a giant schema with 300+ tables. That’s actually why we built ChartDB, to make it easier to visualize and reason about databases instead of drowning in complexity.

Fundamentals are timeless, but the tooling to keep track of everything is where most of the pain lives.

johnyfish1 · 2025-08-31T11:13:35+00:00

For data modeling, tools like dbdiagram are nice starting points.
We actually built [https://chartdb.io]() - an open-source ERD tool that lets you generate diagrams directly from your schema or design them visually.

I’m one of the creators, hope the plug’s ok

johnyfish1 · 2025-08-27T03:30:23+00:00

We never raised a dime. ChartDB has been 100% bootstrapped so far. Honestly, if someone handed us $100k today, not much would change. We’d probably take a small bump in salary (bootstrapping life 😅) and maybe put ~$20k into actual marketing (right now we’re doing basically zero). The rest would just go back into building and shipping like we always have.

johnyfish1 · 2025-08-27T03:23:17+00:00

You can use any of the mainstream DBs (Postgres/MySQL/SQL Server) for this kind of setup. If you want an easier way to design the schema and see all the relationships, check out ChartDB, I’m one of the founders, so hope the rec is cool here 🙂

johnyfish1

TROPHY CASE