It seems that data which needs to answer expected and unexpected many-to-many questions by users might be best kept in nodes that consist of small, or singular, sets of properties linkable through UUIDs of some kind.
In relational databases it makes sense to group properties into sets using tables. This creates rigid data structures and relationships that model entities of all kinds. But if we wanted to ask all kinds of interesting questions of the data which might request unusual relationships, associations or correlations it seems that the schema-on-write structure makes this use case second class or non-intuitive, and the schema-on-read structure makes this easy.
If an application allowed users to compose sets of tags to request properties those tags might be associated with strict types of properties. In a graph database I guess this might be persisted in a separate graph and used as a lookup? Or would tags be added to the existing graph, either onto relationships or in nodes?
Interestingly, schemas seem like they can be modelled in the nodes (using property sets) and/or modelled in the edges - if I understand graphs correctly. But perhaps if the relationships and UUIDs of each property in each node are designed well there may not be any need for schema?
GraphQL (and DQL) seem to be ideal for schema-on-read applications (more so than REST?)?
I have no database management experience so looking for guidance from experienced admins and data modellers. Thank you.
Dgraph has two flavors, DQL and GraphQL. GraphQL is strict schema. What you are looking for is DQL which is loosely schema’d. When you insert/add data to the db using DQL the schema can be defined on the fly or auto detected based on first seen datatype, but it is not schemaless as there is an underlying schema. You then as an db admin decide what parts you want to index and how you want to index it to allow for better querability (some queries are not possible without defining an index).
You can use these two flavors simultaneously if you understand how they map to each other which allows for a strictly defined front end and a loosely defined backend for conglomorating data from various sources. You can also use DQL exclusively. But if you use GraphQL it is actually rewritten into DQL on the fly to query the underlying db. This rewriting is in the core functions of the db hence making Dgraph a GraphQL capable db at its core without qny additional layers/servers.
See my pinned post:
And more of what’s missing from the state of Dgraph here:
Thanks. I realise now that I’m trying to understand how to conceptualise data modelling in Dgraph. Models that fit more dynamic visual user interfaces that are really an abstraction on search.
It seems almost contradictory to think of basing graph modelling on traditional schema design thinking because of a graph’s expressiveness.
It seems like a graph is capable of expressing multiple schemas at once and not limited to technically rigid associations (as in the case of tables and joins).
In trying to understand how to conceptually model and apply it to Dgraph I came across a reference to topic mapping and associative data modelling in this post: