Can’t you just reference, have reference of references, and/or wouldn’t precomputing data imply that you have reference of references. Also there’s now a left outer join or something, how’s join different to referencing.
The biggest issue with that post is not knowing how to properly model data. Seriously.
Joining data also really isn’t that hard with Mongo at an application level. Especially with Meteor and pub/comp level frameworks which will also be mostly irrelevant with graphql/apollo.
MongoDB is great at some things and poor at others. The biggest thing to avoid in my professional experience is to not nest your documents deeply. Yes that means you’ll have to join your data in some way but there’s plenty of abstractions for that.
Really the biggest concern with MongoDB and specifically Meteor is properly sharding the data at scale in relation to the oplog. That’s a hard problem.
2 Likes
I’m just trying to get my first mongo joins working and so far using helper functions its been easy. I’ve got 10 years in experience in MySQL and sometimes find it really hard to not want to just switch to MySQL.
I have to see how Mongo performs at a higher level but in regards to sharding that is something you don’t want in MySQL neither.
Oh no not this again. Come on people.
We are at an era where databases are getting replaced by backend services and apps relying on multiple of these services.
We are all now joining the data from completely unrelated services on the app level.
And while people cheer and applaud for this and tech that work on such basis (like graphql/apollo), it is all boo boo when there is no native joins on mongodb.
What a double standard…
7 Likes
Honestly, I actually fully relate to that article and is probably the main reason that I won’t create another new Meteor app until Apollo is out and stable enough and supports SQL.
MongoDB is “probably” good at some things (I say probably because I’ve never personally come across a good use case but it’s so popular I’m sure it must be good at some things) but it’s just not a good fit for most web apps. Everyone’s saying she didn’t know how to model her database, and to put everything in their most collections.
But if you do that, you’re making everything “relational” then why wouldn’t I just use a SQL database which is designed for relational data? Why would I want to implement my own joins on the app level and de-couple my data from my data integrity? Isn’t your data the most important thing in your system? Why would you implement your own data integrity instead of relying on systems built with decades of relational database research.
And I know there are some advantages of MongoDb like the ease in data sharding and that’s possibly true, but if I ever come across that problem I would say it’s likely a problem I want to have and am happy to tackle that problem when it arises because it means that my app is being used so much that I need multiple database instances to handle my traffic.
But I use Meteor because of the ease to mock up something fast and I think most people do too. And I don’t think worrying about how much data your system can handle is really a concern right off the bat. Most likely I worry more about structuring my data schema appropriately.
IMO, being married to MongoDB is the worst part about Meteor cause they just seem like a odd fit for each other.
1 Like
[quote=“serkandurusoy, post:4, topic:22390, full:true”]
We are all now joining the data from completely unrelated services on the app level.[/quote]
If you think that you can freely exchange one data source for another “in this era”, the you’re sadly mistaken.
I’ve worked in the EDI business and know that such aspirations usually end in wailing and the gnashing of teeth.
It is never free. It comes at a cost of offloading some of the data storage and retrieval paradigms and patterns to the application level rather than relying on a single source of external truth.
Believe me I know the data evolution story. I’ve been working with data (databases and otherwise) since the early 90’s.
Today’s relational “luxuries” (transactions, relations et al) were invented so that we did not have to reimplement them every time on the app layer.
EDI is another story, though. The “sad” story of EDI is that it relied on data formats and overlooked the “interchange”, which, today’s transport protocols and API definitions know and implement in a much more dependable manner.
Riiight. You go right on believing that. 
I don’t think you actually know what EDI is.
Plus, I’m not really seeing the big advantage here - before: joins and transactions on the db. Now, in this “new era”: joins on the client, transactions if you’re really lucky.
Looks more like a regression to me.
Well we clearly do have very different experiences and opinions based on this subject. All in all, I find the “why you should never use mongodb” argument “unconstructively divisive” and you and I are clearly falling for that trap.
I respect your experience and hope you do the same, not assuming one’s knowledge of a topic per a few statements. But well, maybe I don’t know what EDI is…
1 Like