Overall I think the only reason for going with MongoDB is performance.
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.
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.
I find XML an easier example of why it's important that the database treats a semi-stuctured store as a first class entity, let's compare Oracle and SQL Server: SQL Server: http://msdn.microsoft.com/en-us/library/ms189887%28SQL.105%2...
Oracle: http://download.oracle.com/docs/cd/B19306_01/appdev.102/b142...
MS SQL Server:
"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."
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.
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.
Isn't that reason for almost all decisions regarding which db to use? Going with the db that performs the best while suiting your specific needs?
it doesn't have any built-in revisioning like CouchDB
Linux nginx mongodb php
Found this at the end of the article, made me chuckle.