Personally, I'm drawn to Mongo, etc. because I can develop in my language of choice, and not have to write/debug SQL of any dialect to store and retrieve my data.
Personally, I'm drawn to Mongo, etc. because I can develop in my language of choice, and not have to write/debug SQL of any dialect to store and retrieve my data.
An ORM with a relational database would let you do the same thing.
SQLAlchemy in Python is reasonably good for a project nearing a 1.0 release and Linq works nicely with C#. Virtually every other major language has at least one ORM available to it.
That is not to say that a relational database with an ORM is the way for you to go at all, just that avoiding writing SQL code it probably not the best reason by itself to choose your database platform.
An ORM is an abstraction layer. Abstraction layers leak. Fancy abstraction layers like Hibernate add at least as much complexity themselves as learning raw SQL afresh.
I've learned my lesson - if I'm working over SQL, I'll use SQL. Either via the direct record oriented API of the language, or using a thin abstraction like iBATIS that wraps the inputs and outputs into convenient data-carriers.
MongoDB is different. The "document" is real to the database. When you're saying something like "add a foo to the list of foos of record X", that is pretty close to the low level action that actually gets performed on disk. There is no abstraction-translation step to get out of whack.
I've used sqlalchemy, i've used django, and here's the thing, _every_ time I've used them, I've needed to know and understand SQL to learn/write and debug them.
Eventually, some bug comes up, and you need to peek at what queries the ORM is generating, and then peek at what is actually in the database, and etc.
But at this point, you have to not only know what's going on with your particular SQL dialect, you also have to know syntax hoops for whatever particular ORM you're using. Instead of even just language + SQL, you've got language + ORM + SQL , which is even worse for focusing on whatever I was trying to build in the first place!
Whereas, with a NoSQL solution, you're (probably) dealing with JSON, which works nicely and reliably and transparently in pretty much every language ever.
I'm drawn to mongo because it's easier to make changes to my data structures. I do wish, though, that it had a better query language. Something a little more structured. Some kind of structured query language. Queries-as-nested-json structures are kind of annoying.
I'd say the problem is less that it's inflammatory and more that it's totally useless. NoSQL as it is used encompasses a whole array of totally different technologies, everything from a bigtable style column store to redis, to memcachedb.
doesn't it worry you, then, that your reasons for selecting the technology are unconnected with the big differences noted above? or do you think that "different beasts" boils down to what language you use?
no, in my experience building real world stuff, they are both data stores, and pretty similar beasts; most of the docs I see arguing one way or another focus on, imho, silly nitpicky differences.
Personally, I'm drawn to Mongo, etc. because I can develop in my language of choice, and not have to write/debug SQL of any dialect to store and retrieve my data.