Data modelling: related types/tables vs nested json


#1

I read in this thread that you can also use json fields to nest data this thread

This is my structure:

training
    exercises
        repetitions

One training (schema) has n exercises, one exercise has n repetitions
Normally I would put this inside one json object per training, since the data is relatively ‘static’ and used as template for workouts.

However, I could also define separate types (Training, Exercise, Repetition) and make the structure fully related.

Question: which method would be better in terms of ease of querying/mutating data later on? I’m still new to graphcool so I can’t fully oversee the consequences of design choices yet.


#2

One way I’d look at this is that with JSON, that should mostly likely be data that you will always want back in one chunk, and never want to query against (ie, either filtering the contents or using the contents as the comparator within a filter). Also if the data tends to have complex relationships (ie, not purely hierarchical, but multiple objects referencing other objects in a star/net-like pattern as opposed to a tree-like pattern) JSON would not be a good option.

The other use case might be for truly unstructured data, ie when you have hierarchical data from the user but no way to predict how that data is structured. Even in this case, you should still be careful. For example, right now I have an application that allows users to define custom descriptors for various models, but what I’ve done is created a “fields” type (describing this “pseudo-property”) and a “data” type (defining entries for that particular field. This way I can query against that data more easily.

It really boils down to what kind of data you’re trying to represent, and how you’ll be interacting with said data.


#3

hm, correct my if I’m wrong, but I’m beginning to see that json blobs are useless within the context of graphql language. Using json, I could only fetch the json field with graphql, after which I would have to write my own methods in order to query or change stuff inside the json structure( re ordering, adding, removing, searching)
So long story short:

  1. graphql language works best with normalised data?
  2. only put static data or data without clear structure in json fields?

After years of noSql we’re heading back to good old fashioned relational schema’s :wink:


#4

That’s how I’d look at it. If you have normalized data and/or defined relationships between said data, define it within GraphQL. GraphQL does in essence work more like a relational DB than a document/key-value DB. Personally that’s how I prefer working, but I’m sure there are many case in which less structure would make more sense.