it doesn't have any built-in revisioning like CouchDB
This is probably one of the most mis-understood features of CouchDB. It's not a revision per-se. It's a feature to support MVCC. It's not meant to show the history of the document over time and it's not guaranteed to be there for all time. If you compact the database the past revisions will be deleted. Referring to the revisions as a feature is somewhat of a misnomer. They are there to enable a feature(MVCC and as a per document consistency check on writes) but aren't really a feature in and of themselves.
Most of the things the article talks about are actually possible in a SQL database. You can easily store JSON data in table rows if you want; foreign keys and joins are just further options that SQL offers you and MongoDB doesn't.
I also don't understand the argument for a schema-less database. After all, you always have a schema; in a SQL database it is explicit, whereas in MongoDB it is implicit. Seems similar to the argument between proponents of dynamic and static typing.
Overall I think the only reason for going with MongoDB is performance.
Hey there -- article author here. Thanks for reading.
Storing JSON data in a SQL database is possible but not practical. For one thing, it's very difficult to query the individual fields within that JSON data. You also can't retrieve a portion of the data, or do atomic updates to individual fields, etc. It's something I've done before and it's just not pleasant.
The schemaless thing is to some degree a matter of taste, yes. What's not a matter of taste, as I mentioned in the article, is when you have to run an alter statement on your huge SQL dataset that takes down your site for hours.
But I don't believe that one size fits all. Some websites will be better off with a RDMS. Mongo's better for us. Again, thanks for reading and commenting.
> For one thing, it's very difficult to query the individual fields within that JSON data. You also can't retrieve a portion of the data, or do atomic updates to individual fields
I think this may be possible to some degree using the scripting capabilites of the RDBMS, but I don't know for sure. Even then, I have to agree that in Mongo it is much easier to do because it's built-in.
> when you have to run an alter statement on your huge SQL dataset that takes down your site for hours.
That's indeed a problem. I wonder if there's a SQL database that allows instant schema changes; I can't see a reason why it shouldn't be possible technically.
Performance is only one reason I've chosen MongoDB for my new app. I actually don't see the performance factor yet as I'm still developing and would see good enough performance on any number of DB choices.
The benefit I am seeing right now is development agility. I'm writing my app in ruby/merb. I created a simple lib for mongodb's ruby driver to give me simple first class object wrappers for my JSON data structures. I do not need to declare schema stuff anywhere. I can also write ruby scripts outside the merb server proc easily without going through an ORM framework.
As I have another in-production app also using merb using postgres through datamapper, I have a clear comparison to believe I'm realizing productivity gains with mongodb.
"Note the following general limitations that apply to the xml data type:
* The stored representation of xml data type instances cannot exceed 2 GB.
* It cannot be used as a subtype of a sql_variant instance.
* It does not support casting or converting to either text or ntext. Use varchar(max) or nvarchar(max) instead.
* It cannot be compared or sorted. This means an xml data type cannot be used in a GROUP BY statement.
* It cannot be used as a parameter to any scalar, built-in functions other than ISNULL, COALESCE, and DATALENGTH.
* It cannot be used as a key column in an index. However, it can be included as data in a clustered index or explicitly added to a nonclustered index by using the INCLUDE keyword when the nonclustered index is created."
Ok, so that's a pretty constraining set of restrictions. Just look at the lack of grouping, sorting, built-in function support.
And Oracle? Well it does all of that and allows for partial updates (update one Xml node or attribute and not the whole document). Oh, and Oracle fully implements XQuery too.
The difference between just storing something in a database and having the database understand and treat that something as a first class entity is massive.
I've used Xml as an example because it's well documented and understood, but the example extends to JSON/BSON easily enough.
I agree with your statement. I'm just unhappy that the article gives arguments in favor of Mongo that equally well apply to any SQL database. I would have liked more insights into the actual performance differences.
But I don't think they do (apply equally well), sure you could do some of these things in a SQL database but they would be less than optimal. Mongo is built to do these things and seems to do them well.
It's about using the right tool for the right job.
