What about for IoT devices? I could see NoSQL still having a place there, although I could also see it working just as well with a SQL database.
Startup Engineers and Our Mistakes with MongoDB
41–50 of 118 posts
Re: Startup Engineers and Our Mistakes with MongoDB
#42Earlier quoted context omitted.
It that point it's harder for me to understand why I'm not just writing out JSON files or something.
You definitely can but MongoDB provides convenience over storing and managing JSON files on you filesystem by your own efforts.
Sure, but it is also another service to keep running. Depends on what scale you're operating at.
Re: Startup Engineers and Our Mistakes with MongoDB
#43> Schemas: Schemaless does not mean no schema; instead, it means an implicit schema in the app (a particularly challenging misnomer for anyone outside our industry)
Still a challenge for many in the industry.
Re: Startup Engineers and Our Mistakes with MongoDB
#44Earlier quoted context omitted.
"Today in 2017, there is no real reason to use Oracle other than in prototyping. I am happily waiting until the final nail is put on the coffin of this overhyped, flawed relational store." Point being you can say just about the same thing about any other database. They are all flawed for one reason or another. I happen to like Mongo quite a lot, but I rarely use it. You need to understand what situations it works bes…
Oracle RDBMS isn't flawed. It is expensive, complex to configure/mantain/extend, expensive in licensing, expensive in storage, and also expensive. Did i mention expensive? PostgreSQL is eating Oracle's customers little by little. RDBMS aren't flawed at all, this is technology that has been perfected for the last 40 years. What is flawed is to think that relational data can be easily stored on a document store (typica…
Spoken like someone who have never used Oracle with something other than Java. Also expensive seems like a flaw to me.
Re: Startup Engineers and Our Mistakes with MongoDB
#45Re: Startup Engineers and Our Mistakes with MongoDB
#46It terrifies me to see this quote from their CTO: "MongoDB's CTO disagrees with this statement arguing that nearly 90% of database installations today would benefit from being replaced with MongoDB." I used to attend "office hours" at MongoDB's office where guests ask MongoDB employees for help. Most of my questions involved very complex aggregation queries (that would have been trivial in SQL) that even MongoDB empl…
MongoDB is web-scale.
So is /dev/null.
Re: Startup Engineers and Our Mistakes with MongoDB
#47Today in 2017, there is no real reason to use MongoDB other than in prototyping. I am happily waiting until the final nail is put on the coffin of this overhyped, flawed document store.
Why? I don't personally care if MongoDB succeeds or fails, but if they can listen to their users, fix their issues and come out the other end with a database that works as advertised what is wrong with that? Why is it so important to you that they fail?
Why is it so important to you that they fail?
If it fails, then I can quit having the same discussions repeatedly as try to talk my co-workers out of using it.
Re: Startup Engineers and Our Mistakes with MongoDB
#48Re: Startup Engineers and Our Mistakes with MongoDB
#49A really great writeup. A revealing exploration of the perils of mongoDB, and of the greater issue of selecting technology for a project.
There is never any mention of usecase, in companies. Everyone is still trying to be google or facebook, and uses "their tools" without a use case for why. It's just because that's what everyone else does.
All technology has a place somewhere for some use - but we need to know why we are choosing them.
For example, I choose Ruby on Rails because of it's gains in productivity, reliability, security and pleasure of use. I can quickly sling maintainable code that can scale up to millions of users. And most importantly, I don't have to make a lot of decisions. Best practices are defaulted into the framework. Some people shy away from frameworks, favoring "simpler" tools - but that only means they have to re-solve all the problems the framework has already solved.
Likewise, with MongoDB, all those useful things SQL databases do for us need to be resolved. But, that's a database decision, and many people making the decision are just developers in search of a data store. Transactions and ACID are often not even on their radar.
Overall, i think this is a symptom of a lower barrier for entry. Where before you needed a CS degree to be a programmer, now you just need to go to a bootcamp. People are not properly trained, aware (or interested) in the underpinnings like databases, networking or security - and to their own peril and the peril of the companies they work for.
Re: Startup Engineers and Our Mistakes with MongoDB
#50It terrifies me to see this quote from their CTO: "MongoDB's CTO disagrees with this statement arguing that nearly 90% of database installations today would benefit from being replaced with MongoDB." I used to attend "office hours" at MongoDB's office where guests ask MongoDB employees for help. Most of my questions involved very complex aggregation queries (that would have been trivial in SQL) that even MongoDB empl…
> "MongoDB's CTO disagrees with this statement arguing that nearly 90% of database installations today would benefit (MongoDB shareholders) from being replaced with MongoDB."
If Mongo's DB was half as good as their marketing team they would really have something useful.