Hierarchical schemas aren't that problematic in SQL. Say for a tree structure of same data type it's enough to add a single indexed foreign key column "parent".
Getting parent entity from such structure is obvious and for getting child entities, one would do a simple self join.
For graphs, one can create a table that contains two foreign key columns to store graph edges.
Although writing graph algorithms in plain SQL would get hairy, but luckily databases such as PostgreSQL support writing stored procedures in other languages, so one can write highly performant hierarchical data algorithms that run on top of database server.
I've been coding for over 20 years now! (WOAH, do I feel old)
I've touched just about every resource imaginable under the Sun (too bad they were bought out by Oracle)
Doing tree or graph querying isn't even that hairy in SQL anymore. Its part of the SQL standard at this point and supported by most database engines :) This is something I use quite extensively nowadays.
Hierarchical schemas aren't that problematic in SQL. Say for a tree structure of same data type it's enough to add a single indexed foreign key column "parent".
Getting parent entity from such structure is obvious and for getting child entities, one would do a simple self join.
For graphs, one can create a table that contains two foreign key columns to store graph edges.
Although writing graph algorithms in plain SQL would get hairy, but luckily databases such as PostgreSQL support writing stored procedures in other languages, so one can write highly performant hierarchical data algorithms that run on top of database server.
Doing tree or graph querying isn't even that hairy in SQL anymore. Its part of the SQL standard at this point and supported by most database engines :) This is something I use quite extensively nowadays.
mariadb.com/kb/en/recursive-common...
That's interesting, I had used common table expressions before but had no idea their recursion can be used for hierarchical structure querying.