4 ms·
This is quite similar to the RDF triples model. Everything is a 'thing' including 'relationships' between things. So you just need a thing table and a relation
by vivegi 4y ago
This is quite similar to the RDF triples model. Everything is a 'thing' including 'relationships' between things. So you just need a thing table and a relation table.
The issue with this is schema management and rules gets pushed to the application layer. You also need to deal with very massive tables (in terms of # of rows) for the relationships table which leads to potential performance issues.
- replygirl 4y agolet's call them "nodes" and "edges"
- CabSauce 4y agoRight? What a groundbreaking idea! /s
- claytonjy 4y agoother downsides I saw from an implementation of this in postgres: 1.you can't have strongly typed schemas specific to a 'thing' subtype; to store it all together, you end up sticking all the interesting bits in a JSON field 2. any queries of interest require a lot of self joins and performance craters Please, please, never implement a "graph database" or "party model" or "entity schema" in a normal RDBMS, except perhaps at miniscule scale; the flexibility is absolutely not worth it.
- NicoJuicy 4y agoThat's why you have duplicated properties on things you went to query on.
- philjohn 4y agoThat's why in RDF you should really be using a well-modelled ontology. As for performance issues, using a dedicated Quad store helps there, rather than one built on top of an RDBMS (OpenLink Virtuoso excluded, because somehow they manage to make Quads on top of a distributed SQL engine blazing fast). It's been about 6 years since I've been in that world, so things might have changed wrt performance.