re: Who's going to write us a post on alternatives to mongoose ? VIEW POST

TOP OF THREAD FULL DISCUSSION
re: I use both relational and document. The reason I choose document for a particular thing (usually settings) is because it has a nested hierarchy. Th...
 

hmm.. never thought about it that way, probably because I haven't had to work with such type of data so far. If I use some sort of a nested hierarchy it's usually relational data, and if I work with something that's not relational I often have to deal with dynamically changing model, of which I'm interested only in a small unchanging part (other part are metadata used by the frontend application I have to return, but I don't care about)

I understand. It is very convenient to use JSON as a hash of keys and values without a pre-defined structure. I generally work with typed languages, so regardless of data store my data usually has an expected structure.

Maybe I shouldn't have commented because I don't use Mongo. I put both kinds of data (document and relational) in Postgres. But I just wanted to provide a viewpoint for why someone might want to use structured data in a JSON store. I usually find that configuration settings fit really well into document storage (and doing so instead of chopping this up into relational tables means I don't need an ORM). But relational is very nice to track set memberships and for its built-in indexing capabilities.

Best wishes!

Maybe I shouldn't have commented

At least for me your comment was a valuable insight :)

I generally work with typed languages, so regardless of data store my data usually has an expected structure.

In typed languages I do (obviously) have a model for my data, but in js where (in my case) large part of the model is of no interest to me and changes rapidly, I prefer to just clearly separate data and functionality, and work without model at all. (It does mean I need more validation, but I can put off validation to where I actually need part of the model)

code of conduct - report abuse