| > a universal approach to data, see RDF and SPARQL and numerous pretenders. For that matter, think of a C program where the master data structure is a graph of pointers. A graph of typed pointers. As you likely know, the basic element of RDF is not “foo has a relationship with bar”, but “foo has a relationship with bar of type baz”. Also, the types themselves can be part of relationships as in “baz has a relationship with quux of type foobar” > The thing about graphs is, in general, they are amorphous and could have any structure (or lack of structure) at all which can be a disaster from a memory latency perspective But that’s an implementation detail ;-) In theory, the engine you use to store the graph could automatically optimize memory layout for both the data and the types of query that are run on it. Practice is different. > Thus practitioners tend to be skeptical about general purpose graph processing libraries I am, too. I think the thing they’re mostly good for is producing PhD’s, both on the theory of querying them, ignoring performance, and on improving performance of implementations. |
Now the Lotus notes patents have been long expired so I’d like to see some graph database based products that can do what Notes did 30 years ago but it is lost technology like the pyramids, stonehenge and how to make HTML form applications without React.