Talk:Graph database

The Properties section seems to be quite a jumble of disparate material. The "Storage" and "Index-free" subsections are about lower level details, whereas the "Graph types" subsection rather appears to be about what kind of information may be found in the database. And there is a strong business slant (as opposed to say science) in the choice of categories, so presumably the cited categorisation had a different scope than this article. 37.2.117.154 (talk) 09:10, 30 March 2023 (UTC)[reply]

Made "Graph types" subsection a section of its own, and renamed it. 130.243.94.123 (talk) 14:04, 13 April 2023 (UTC)[reply]

The example of searching for friends of Jack appears to be skewed to me. The graph database examples start by finding the person(s) named Jack and then finds friends of these, but the SQL example first builds a table of all pairs of friends, and only at the end filters out those where the first party isn't named Jack (even if query optimisation may change the order of operations). I think something like

SELECT p2.person_name FROM 
 (SELECT * FROM people p1 WHERE p1.person_name = 'Jack')
 JOIN friend ON (p1.person_id = friend.person_id)
 JOIN people p2 ON (p2.person_id = friend.friend_id) 
;

might make a more fair comparison (but I'm not confident enough with my SQL that I trust I got the syntax right).

Also, a discussion in a general article such as this one should probably spell out how one even would store graph-like data in a relational database, before getting into pros and cons. Assuming triples, I suppose two approaches would be:

1. Make one big table with columns subject, predicate, object.
2. Make a separate table for each predicate, with columns subject, object.

The second approach would require changing the schema whenever adding a new predicate, which could be considered a big deal. The first suggests naive estimates for any basic operation would depend on total number of edges in the database (rather than, say, vertex degree), which is probably challenging. 37.2.117.154 (talk) 09:46, 30 March 2023 (UTC)[reply]

A long and detailed explanation for what you are asking about/looking for is given here: https://github.com/opencog/atomspace/raw/master/opencog/sheaf/docs/ram-cpu.pdf it goes into all the hows and whys of how this stuff works. 67.198.37.16 (talk) 04:16, 5 May 2024 (UTC)[reply]

The list of graph databases currently has a strong focus on these as software products — version, release date, licence, and implementation(?) languages all have separate columns — but there is no structured information about the capabilities of these systems! Two columns I'd like to suggest are:

• Graph model: The two main models appear to be property graph and RDF, but it is in many descriptions very difficult to tell which, if indeed any, of these two are supported. And then there is the possibility of minor variants, such as RDF versus RDF-star…
• Query API: A lot of the systems seem to promote their own solution here, but is that all they offer? It is probably useful if a system provides a SPARQL endpoint, even if its native model is not RDF. Some of the interfaces appear to be actual query languages (like SQL: not what you write your app in, but an actual separate language used for stating queries), whereas others are more APIs for building and using query objects.

130.243.94.123 (talk) 14:56, 13 April 2023 (UTC)[reply]

The OpenCog AtomSpace is about 20-25 years old, and is one of the first, if not the first graph database to hit the market (copyright notices give 2002 as the date) Sort of disappointed to not see it mentioned in the listing here. OpenSource: https://github.com/opencog/atomspace It transitioned from proprietary to open source in 2008. 67.198.37.16 (talk) 04:12, 5 May 2024 (UTC)[reply]