Hacker News Reader

Comment by andrelaszlo | Hacker News Reader

> 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!

View on HN

>Just curious about the emphasis on the single query.

Marketing?

And they need a single json to create the diagram from.

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!

Not requiring db credentials is a huge plus! Thanks for the explanation.

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.

does it necessitate foreign keys and schemas being defined beforehand? or is that the "AI magic"?

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.

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.

Still lots of hits and misses.

Column names could sound like foreign keys on pure chance and the data type doesn't show which other table it's referring to.

If you’re allowed to query the data you could use the column name/data type to come up with lots of good candidates, and then if then verify by checking whether the actual values correspond (assuming that it’s something like a uuid or username column and not a serial/int column)

Newbie here. How do you express foreign key - primary key relationships when you define your schema, in Postgresql and/or SQLServer ? Is it via an integrity constraint, or can it be just an informative metadata ?

I’m curious how frequently people actually encounter foreign key constraints in production.

I’m 10 years in and have only ever seen it once

Reply on news.ycombinator.com