The answer for EACH one of your questions is YES !
But, what's the problem with copying one module from a workshop into another since it happens rarely?
Modelling relational data without the referential integrity constraints inherent to SQL is just asking for trouble
But NO, the ACID philosophy turned out to not be not pretty much scalable comparing to the BASE (no black/white case, it always depends).
You mention the need to perform 3 subqueries
As far as I see, we will replace them with just one query: get document (track) by id.
For filtering and shaping the data, I liked the way GraphQL works, we might add that layer on top of the normal query / REST endpoint.
but are you familiar with how onerous and haphazard it is to query/manipulate subdocuments in Mongo?
I know the lookup in mongo is a hell of an operator. But, let's avoid not seeing the forest for the trees... after all, (mongo and nosql) is like (bitcoin and blockchain).
If mongo makes the use of nosql hard, then there is dynamodb or firebase ;)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The answer for EACH one of your questions is YES !
But, what's the problem with copying one module from a workshop into another since it happens rarely?
But NO, the ACID philosophy turned out to not be not pretty much scalable comparing to the BASE (no black/white case, it always depends).
As far as I see, we will replace them with just one query: get document (track) by id.
For filtering and shaping the data, I liked the way GraphQL works, we might add that layer on top of the normal query / REST endpoint.
I know the lookup in mongo is a hell of an operator. But, let's avoid not seeing the forest for the trees... after all, (mongo and nosql) is like (bitcoin and blockchain).
If mongo makes the use of nosql hard, then there is dynamodb or firebase ;)