41–50 of 245 posts
Next up will be SQL compliance, and we'll be back to a relational database. I'm curious as to what the impact to speed will be, and what the use cases for these types of databases is now that the major SQL players support JSON.
MongoDB has successfully played the 'hype first, features later' strategy. Now it is well on the way to being a decent swiss-army-knife database. The RethinkDB retrospective[0] contains a lot of insight into how MongoDB has succeeded despite being vastly inferior on a technical level back when it first launched. I have to admit them a certain respect for executing their strategy so successfully. Choice quote: Every t…
MongoDB has successfully played the 'hype first, features later' strategy. Now it is well on the way to being a decent swiss-army-knife database. The RethinkDB retrospective[0] contains a lot of insight into how MongoDB has succeeded despite being vastly inferior on a technical level back when it first launched. I have to admit them a certain respect for executing their strategy so successfully. Choice quote: Every t…
I agree here, but I’d go further; build things people want, not the idealistic future some day version where we eventually get to a priority feature for a lot of people like releasing fast scalable software quickly (I’m not saying Rethink didn’t do this but they prioritised correctness and sharding, features fewer people need). For most apps built with Mongo this transaction support isn’t a problem (until it is).
FWIW, I don't think this was what happened. RethinkDB started out as an SSD optimized database, and quickly repositioned itself (due to "is this what people want") to something more generally useful, and was one of the most feature-rich databases at the time, I thought.
MongoDB however got first mover advantage and a bunch of cash that comes with it. They could afford to invest heavily in developer evangelism. Then they bought WiredTiger. If I sound bitter, I am a bit - not that Mongo did well in the end, but that RethinkDB went the way it did.
Earlier quoted context omitted.
I've been using MySQL 5.7 since its release in production. I used to store JSON data in a blob, but when they released JSON support - I just couldn't wait to use it. It's working really, really good. JSON support solves a ton of problems we used to have, and we used EAV model to tackle those problems (I won't get into details, the discussion will go the other way). I deal with a few hundred MySQL deployments ranging…
> I often wondered why anyone would use MongoDB or similar, but I always keep forgetting that developers are usually inexperienced hipsters You can do a basic google search, and you will find out use cases where document-based data storages are advantageous compare to relational ones.
Earlier quoted context omitted.
I beg to differ. (Disclosure: I work for MongoDB.) Using JSON as your data model, rather than relational tables, lets you build different applications that don't need multi-document transactions as often, because the data is already together in a single document. But when you do need multi-document transactions (a small percentage of applications do, and only few use cases inside those applications), they are now ava…
> otherwise you wouldn't be capitalizing on the advantages of JSON Shouldn't this be "otherwise you wouldn't be capitalizing on the advantages of a schemaless, document-oriented database"? The fact that it's JSON (vs. some other format) seems immaterial
https://blog.jooq.org/2014/10/20/stop-claiming-that-youre-us...
Does anyone care to give any specifics?
Earlier quoted context omitted.
You're aware that the vendor will post gospel about their product on their own website? I'm not using Postgres, I use MySQL, but I can assert with 100% certainty that most of the "comparison" on that URL is just marketing bullshit. You're a prime example that this new-age bullshit works and that's what's worrying.
great. Do i declare i worked at mysql for 5 years as well? Both before and after Oracle acquisition
Earlier quoted context omitted.
I beg to differ. (Disclosure: I work for MongoDB.) Using JSON as your data model, rather than relational tables, lets you build different applications that don't need multi-document transactions as often, because the data is already together in a single document. But when you do need multi-document transactions (a small percentage of applications do, and only few use cases inside those applications), they are now ava…
> otherwise you wouldn't be capitalizing on the advantages of JSON Shouldn't this be "otherwise you wouldn't be capitalizing on the advantages of a schemaless, document-oriented database"? The fact that it's JSON (vs. some other format) seems immaterial
But your main point is good—- JSON isn’t the essence of it.
And yet it’s part of it, in that you could store XML and still be a document DB; MongoDB definitely chose JSON as the medium deliberately.
Earlier quoted context omitted.
> I often wondered why anyone would use MongoDB or similar, but I always keep forgetting that developers are usually inexperienced hipsters You can do a basic google search, and you will find out use cases where document-based data storages are advantageous compare to relational ones.
So what you're saying that if I find something on google, it's undoubtedly true and I should blindly believe it? For every one of those use cases, I can provide a counter-argument. And there are many more who can do the same.
I'm a Domain Driven Design true believer. The thought of just being able to store my entire domain model without the machinations of the object relational impedance mismatches was glorious.
I use C# so my document collections are strongly typed C# objects and thanks to the Mongo C# Linq provider, my queries are also strongly typed.