3 ms·

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 dat

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.

japherwocky 17y ago
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.
JulianMorrison 17y ago
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.

japherwocky 17y ago

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.

JulianMorrison 17y ago

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.