[HN Gopher] Show HN: Visualize database schemas with a single query
___________________________________________________________________
Show HN: Visualize database schemas with a single query
Hey HN! We are Jonathan & Guy, and we are happy to share a project
we've been working on. ChartDB is a tool to help developers and
data analysts quickly visualize database schemas by generating ER
diagrams with just one query. A unique feature of our product is
AI-Powered export for easy migration. You can give it a try at
https://chartdb.io and find the source code on GitHub. Next steps
---> More AI. We'd love feedback :)
Author : Jonathanfishner
Score : 104 points
Date : 2024-08-24 16:23 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| namanyayg wrote:
| nice work on chartdb, guys!
|
| can you elaborate on how the ai part works? im a bit confused how
| that fits in because there are many SQL diagram tools without AI
| as well
| Jonathanfishner wrote:
| Thank you! We use GPT-4o to generate database schema creation
| scripts for different database dialects. Basically, we wanted
| to add the option to export the db schema to any type of
| database (for easy Migration for example from MySQL to
| PostgreSQL or from SQLite to MariaDB). First, we tried to
| implement that logic, after getting into trouble with too many
| different edge cases and dialect differences between different
| databases we decided to leverage AI in order to achieve that.
| andrelaszlo wrote:
| > visualize database schemas by generating ER diagrams with just
| one query
|
| > visualize and design your DB with a single query
|
| > Instantly visualize your database schema with a single "Smart
| Query."
|
| The tool seems really useful and I will give it a try!
|
| Just curious about the emphasis on the single query. What's the
| value of this? If it makes it much faster than similar tools it's
| probably worth making it explicit. I don't use them often enough
| to know if speed is a big issue (if this is the reason).
|
| Nice work anyway!
| SoftTalker wrote:
| They are querying postgres information_schema tables (or their
| equivalent in the other supported databases) to get table
| names, column names and types, foreign keys, etc.
|
| I doubt the "single query" makes it immensely faster, but
| reducing query round-trips is usually time-saving. Might be
| noticable, depending on what you're comparing it to.
| hackernewds wrote:
| does it necessitate foreign keys and schemas being defined
| beforehand? or is that the "AI magic"?
| croes wrote:
| It has to be in defined beforehand.
|
| No AI magic can know the foreign keys from the schema alone
| and even with data the results would be uncertain.
| scotty79 wrote:
| If you are naming your foreign key fields consistently
| for example extras.products_id -> products.id or using
| some fairly unique data type like GUID for your keys it
| could be intelligently inferred.
| croes wrote:
| >Just curious about the emphasis on the single query.
|
| Marketing?
|
| And they need a single json to create the diagram from.
| Jonathanfishner wrote:
| Thanks for the feedback! The emphasis on a single query
| highlights how easy it is to import your database schema: just
| run the query, get the JSON output, and start editing your
| diagram in ChartDB. Plus, there's no need to sign in or set
| your database credentials. It's all about simplifying the
| process and saving time so you can get started quickly. Speed
| is a bonus, but the main value is the simplicity and ease of
| use. Glad you're giving it a try!
| andrelaszlo wrote:
| Not requiring db credentials is a huge plus! Thanks for the
| explanation.
| gitroom wrote:
| This is cool, but there are a lot of visualizer, what's the
| difference?
| Jonathanfishner wrote:
| Thank you first of all! ChartDB stands out with its one-query
| for visualization, AI-powered migration for easy cross-DB
| transitions, and interactive editing, all free and open-source,
| combining these features in a user-friendly way.
| SahAssar wrote:
| I'm not sold on many of those points, but "AI-powered
| migration" stood out to me (as something that seems like a
| risky idea with many unknown consequences). What do you mean
| by that and how would it be deployed?
| djray wrote:
| I rather think using AI to generate scripts for other DBs is a
| disadvantage. Scripting is a deterministic process, surely? Can
| you create a common internal representation and write exporters
| for each supported DBMS from that? Maybe the JSON format you use
| is a path toward this.
|
| I dislike the multiple references to 'Magic' on the site, but I
| realise that's probably a subjective thing. Maybe I'm fatigued by
| the AI-in-everything trend.
|
| I don't use all the DBMSes you support, but I'm not sure having a
| single query to run is really much of a selling point. For SQL
| Server, I'd rather execute a stored procedure with permission
| checks, and progress feedback, than a big chunk o' SQL. (Again,
| that may just be a me thing.) If it's an efficiency thing for
| very large DBs then I think you should emphasise that, and also
| detail how much faster it is to gather all the info in one fell
| swoop than if you split up the queries.
|
| The Examples link is currently broken on your site, btw. That
| sounds like a really useful way that people can evaluate your
| application without having to run a query on their own DB, which
| they may be reticent to do for testing out a new app.
| Jonathanfishner wrote:
| Thanks for the feedback! We aimed to make database migration
| easier and found that AI could really enhance this process by
| handling the complexities of different DB dialects. We'll also
| explore more deterministic approaches, as you suggested, using
| a common internal representation. The "Examples" link is being
| fixed--thanks for catching that!
| samstave wrote:
| huh.. I like to have claude give me a DB schema in a mermaid
| diagram, infact - I make python scripts to log into the DB, list
| the DBs, list the schemas, and make a mermaid diagram of the
| schema and then I have a python script that converts the mermaid
| code to an SVG.
| hackernewds wrote:
| what is your input to Claude
| ok123456 wrote:
| How is this different from Schema Spy (https://schemaspy.org)?
| layer8 wrote:
| It supports fewer databases. ;)
| jesperwe wrote:
| I tried it out on a not so complex Postgres v15 DB. No relations
| were imported, just the tables?
| ellyagg wrote:
| Awesome! This is exactly what I wanted last year when I was
| helping my wife with her reporting and the only access she had to
| her company's application database was through Redash.
| yetanotherdood wrote:
| I think having multiple "views" of these diagrams would be nifty.
| In addition to the standard visualization, you could have an
| "index" visualization that also captures foreign keys etc.
| rustman123 wrote:
| "PostgresSQL"? "SQL Lite"? Not even getting the names of the
| supported databases right doesn't create trust...
| doctorpangloss wrote:
| On the other hand, the chatbots let enthusiasts like these guys
| write code. There are millions of them. And each of them, even
| if they are 1/2 as good as you rustman123, for starters they
| will learn the right names for things, that's not challenging,
| and secondly, they have more time than you have for this
| problem, which you have zero.
|
| The chatbots are the Zero to One for programming.
|
| So listen I agree with you. I'm not going to use this. But
| hundreds of thousands of smart people with time, like these
| guys, can now author stuff that will get better over time
| faster than you personally will solve any one particular
| problem for anyone. So something something, log in your own eye
| before the thorn in the other.
| salzig wrote:
| > STRING_AGG aggregation result exceeded the limit of 8000 bytes.
| Use LOB types to avoid result truncation.
|
| Looks like not all databases (mssql in this case) like the
| generated result.
| Eji1700 wrote:
| Yeup. Seconded. MSSQL as well. Was curious what the output
| would look like given it's a fairly large db (a crap ton of
| mostly useless tables kept for archival purposes).
___________________________________________________________________
(page generated 2024-08-24 23:00 UTC)