21–29 of 29 posts
Earlier quoted context omitted.
Not sure I would have made mine if I had come across yours first. https://github.com/TomConlin/SQLiteViz
wondering finished. Thx!
Foreign Keys are great! Too bad they were not invented until SQL-89, and could thus not be considered when the JOIN syntax we all know was designed and formalized by ANSI in SQL-86. Imagine if we could simply give the name of a foreign key, as an argument to JOIN, letting the query planner look up the foreign key columns, to do the join on. The default names for foreign keys are not very user-friendly, due to the SQL…
TIL!
> After renaming the foreign keys
The idea about using FK as a JOIN target is interesting. While developing a syntax for PostgREST resource embedding[1], I also reached the conclusion that FKs would be a convenient way to join tables(also suggested renaming them as you do here).
IIRC, self joins are still an issue with FK joining.
[1]: https://postgrest.org/en/v7.0.0/api.html#embedding-disambigu...
I'm building a 3D database that lets you explore graph and relational data that you've created. For research or creating your own mind palaces - you can freely join & filter collections of information. But it's more like a 3D excel of sorts.
I'm curious what you're using to build this. I've been playing around with a similar idea, and have been prototyping in Godot. Visually representing the connections/structures between items has been a sticking point, but I've settled on two main abstractions: stacks and surfaces, mapping to 1D and 2D arrangement. I've been hesitant to explore 3D, as it unlocks many novelties in the design of a micro-world; but I do t…
As part of my research, I'm also building a new UI for exploring a database using data visualizations and an ER diagram. Here is a half-baked demo: http://mondial.kyrixdemo.live/ Hopefully the UI is self-explanatory - if not try clicking on visual objects to perform drill down, or search something in the top righthand corner. The underlying dataset is a public DBMS called MONDIAL: https://www.dbis.informatik.uni-goet…
This is fantastic, thanks for sharing! The unique ability to drill down into connected tables and visualize the relationships and data within is unique (for me at least). Are you building this as a personal tool or building it in a manner to apply on any database? Would love to know more
You can checkout our Github repos if you are interested: https://github.com/tracyhenry/kyrix https://github.com/tracyhenry/kyrix-j
As part of my research, I'm also building a new UI for exploring a database using data visualizations and an ER diagram. Here is a half-baked demo: http://mondial.kyrixdemo.live/ Hopefully the UI is self-explanatory - if not try clicking on visual objects to perform drill down, or search something in the top righthand corner. The underlying dataset is a public DBMS called MONDIAL: https://www.dbis.informatik.uni-goet…
This is cool. The node label should display the name of the table for some reason it seems to be missing. Is this open source?
Also, it is open source: https://github.com/tracyhenry/kyrix https://github.com/tracyhenry/kyrix-j
Earlier quoted context omitted.
This is cool. The node label should display the name of the table for some reason it seems to be missing. Is this open source?
Yep currently you need to hover over a node to see the table name. We need to find a way to show the labels without generating too much clutter. Also, it is open source: https://github.com/tracyhenry/kyrix https://github.com/tracyhenry/kyrix-j
Foreign Keys are great! Too bad they were not invented until SQL-89, and could thus not be considered when the JOIN syntax we all know was designed and formalized by ANSI in SQL-86. Imagine if we could simply give the name of a foreign key, as an argument to JOIN, letting the query planner look up the foreign key columns, to do the join on. The default names for foreign keys are not very user-friendly, due to the SQL…
> Too bad they were not invented until SQL-89, and could thus not be considered when the JOIN syntax we all know was designed and formalized by ANSI in SQL-86. TIL! > After renaming the foreign keys The idea about using FK as a JOIN target is interesting. While developing a syntax for PostgREST resource embedding[1], I also reached the conclusion that FKs would be a convenient way to join tables(also suggested renami…
Many thanks for making PostgREST, I'm using it for all my projects!
I'm trying to understand the problem you see with self joins. Why would it be a problem? At the end of my comment, I gave an example with a users table, for such a table, an expression such as "FROM users JOIN users->parent" would join-in users two times, but two different rows of users, since "users->parent" would follow the foreign key "parent".
I'm building a 3D database that lets you explore graph and relational data that you've created. For research or creating your own mind palaces - you can freely join & filter collections of information. But it's more like a 3D excel of sorts.