7 ms·
A few weeks ago, a friend of mine asked me for help with PostgreSQL. As someone who’s been blissfully SQL-free for a year, I was quite curious to find out why
by corresation 14y ago
A few weeks ago, a friend of mine asked me for help with PostgreSQL. As someone who’s been blissfully SQL-free for a year, I was quite curious to find out why he wasn’t just using MongoDB instead.
The lead in seriously harms the technical credibility of the rest of the entry.
- angstrom 14y agoHaving done a large personalization project (25 million+ users) with Mongo as a proof of concept I tend to agree. It's great for small POC, but it still has problems under large applications. We took tailored our data collections to take advantage of memory locality, but for that project it wasn't a good fit. I'm more interested in Hyperdex at this point. Mongo is great for getting something up and running quickly.
- corresation 14y agoMongoDB is very suitable for some tasks (though it has the inevitable young product edge issues that early adopters get to enjoy), but my core issue with the lead-in is that the author sounds like the problem with NoSQL, which is the "everything is a nail, here is my hammer" mentality, assuming that products like MongoDB are the successors of RDBMS', when that is absolutely not true. They are different tools for different purposes.
- tomsthumb 14y agoWhat are the different purposes, and how do I know that have have one versus the other, versus another, etc?
- niggler 14y agoUltimately most of the technical differences boil down to a single tradeoff between performance and reliability. In some use cases, you have many transactions against a data store that won't be modified once it is set. In a case like that, mongodb is acceptable. In other use cases, you have more complicated transactions involving lots of separate logical units. For example, lets say you are building an inventory and order management system. Someone wants to buy a widget. You need to reduce the widget inventory and push it into a customer's order, essentially an "Atomic" operation. AFAICT there's no "simple" data model under which MongoDB can give you atomicity. In order to make a decision, the best bet is to figure out those requirements and just try one that fits the bill.
- vec 14y agoSQL databases are strongly typed and extremely good at enforcing consistency, whether you want them to or not. They are quite good at preventing many classes of bad data from being recorded in the first place, and allow you to do some types of low level data manipulation (joining datasets, eliminating duplicates, finding mins and maxes, etc) extremely efficiently. NoSQL, on the other hand, is weakly typed and makes few if any attempts to validate your data, pushing that responsibility back onto you. They are very well suited to storing inherently inconsistent data (which, as a corollary, makes them very good for prototyping, when your data model is rapidly changing and growing). They also allow you to link much larger datasets into a 'document' which is retrieved as a unit with no extra computation. So it mostly boils down to what kind of data you want to store. If you find yourself almost exclusively saying things like "All users have a username that is a string" or "I want to be able to find all products that cost less than $20" then you're probably looking for a traditional SQL database. If, on the other hand, you find yourself saying "some products have a width and height, but some just have a height, and a few have a volume instead" or "I want to be able to add custom fields to products on the fly" or "I never want to see purchases on their own, I always want to see them joined to the user that bought them" then you should probably consider a NoSQL solution.
- tomsthumb 14y ago> SQL databases are strongly typed and extremely good at enforcing consistency, whether you want them to or not. They are quite good at preventing many classes of bad data from being recorded in the first place >NoSQL, on the other hand, is weakly typed and makes few if any attempts to validate your data, pushing that responsibility back onto you. They are very well suited to storing inherently inconsistent data Actually, I've had to deal with that first hand. It gets particularly nasty when multiple languages with varying type-tightness interact with the same data. It's nice to hear someone else put this into words.
- niggler 14y agoLets be fair here: this is on mongodb.com, so of course mongodb will be hailed as the third coming of Christ.
- obviouslygreen 14y agoIf this were just a good article about Mongo, sure, that's fair. But I don't think "fair" can be stretched all the way to "let's not be critical of biased comparisons simply because we expect the source to be biased."
- niggler 14y agoDo you honestly expect a product or company blog to give an unbiased account of the product or company?
- pekk 14y agoI don't always rely on people to be honest, but I do expect them to be honest. Why does business have to be built on dishonesty?
- niggler 14y agoHuman nature. People get burned when they assume honesty and find that counterparties are dishonest. It's harder to get burned if you go into business or other intellectual relationships without expecting honesty. And I think, push come to shove, many founders will do what is necessary (no matter how unscrupulous) to keep their startup alive or to ensure the big payday, even if it comes at the price of turning back on promises or contracts with customers I recommend you read http://www.zerohedge.com/node/13972 http://www.zerohedge.com/node/13972 (the Conflicts/"Full Disclosure" Policy for zerohedge.com) as I think it captures the point very well.
- eCa 14y agoIt's a very good way to bring trust to your brand. If you honestly say: "This is good with <product>, this is bad with <product>". If you do that enough, and isn't afraid to say that in <particular circumstance> a competitor's product is better, you might in time be seen as something more than a salesman.