MongoDB straps SQL to Google's MapReduce To NoSQLers he's the Devil who flames their work. Bring up his name while interviewing the CEO or founder of any NoSQL start-up, as I have, and the interviewee withers to a tight smile. Say "Michael Stonebraker" to the database wizards of today, though, and they'll nod sagely at mention of the pioneer of relational database …
"Crucially, they also dispensed with needing to grapple with another language: SQL. CouchDB devs can code using Erlang instead while MongoDB uses C++."
SQL is the language used to interact with a SQL database. Erlang & C++ are the languages used to develop those DBMSes you mentioned.
To interact with MongoDB you use a variety of Javascript. I don't know about CouchDB but I suspect something similar.
"CouchDB devs can code using Erlang instead while MongoDB uses C++"
I can't speak for MongoDB, but having used CouchDB for a while that is not really true. Sure, if you wish to mess with the internals then Erlang it is, but so far I've done all my views with Javascript. You can code views in Erlang as well, and apparently they perform better, but at least so far with the moderate amount of data we're dealing with JS has been fine.
Both CouchDB and MongoDB have a friendly JavaScript Object Notional interface that integrates nicely with web-technology, but duck the last of the ACID (atomic, consistent, isolated, durable) criteria because “durable” is the only one that really distinguishes a “database” from a memory cache.
MongoDB has added logging primarily for recovery, and with SSD drives and fast tick-time gets pretty close to ACID durability, but without guarantee it is just like driving an old Ford Explorer that carries big loads in comfort and rarely crashes with brake failure: good for moving manure, but not for moving kids.
The current crop of NoSQL is good for social networks but not for financial transactions.. the answer is not necessarily transactional logging like {Ingres,DB2,Oracle,SQLServer}, but could use the distributed callback method of message-queues.
Y'know, there's a reason why it's called the "CAP Theorem", and not the "CAP Hypothesis".
A database can't be consistent and atomic and partition-tolerant. That means any database - SQL or not, cloudy or not - can't both be ACID and tolerant of partitioning (due to network problems, for example). And that means any ACID "cloud" database is not so cloudy after all; if it's really distributed, then it's not really ACID.
Many applications can do without true consistency or atomicity (often by repairing the data when the network is re-established), or can live with being unavailable if the network's partitioned. But an always-on, true-ACID database cannot be subject to partitioning. That's a fundamental limit on distributing data.
There are clearly applications for which NoSQL solutions are the best fit – in particular, ones that have frequently-changing data models and require no transaction support. However, in their froth to embrace shiny new objects, some developers have lost sight of proven engineering virtues – standards and knowledge portability matter a lot, and ACID transactions are non-negotiable when data must be 100% accurate 100% of the time. Choosing the right tool for the job has never been more critical. A slightly deeper dive can be found here: http://bit.ly/xLh8Y3.
Just what is the problem so many people have with SQL and relational concepts in general?
SQL is a small, simple language. It's not without a few ugly features, but it's easy to learn, clearly defined and consistent. Relational databases are simple enough that Edgar Codd could define one in 12 rules. (Simple, that is, from the perspective of the schema designer and application developer - DB administration is something else.)
But numerous apparently intelligent developers seem to fear these things as children fear to go in the dark. I'm forever hearing bleats of "do we really have to have a primary key?", as if the cost of the key was being deducted from their salary. Time and again I start work with a database and find that the schema was created by people who couldn't see the point of foreign keys, so the tables are full of junk values. And don't get me started on normalization.
This stuff is all so difficult that we have to re-invent the wheel, only this time we'll make it elliptical.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
