NoSQL vs SQL, Why Not Both?

Alaric Snell-Pym^[1]:

But there’s no real reason why an SQL SELECT statement is difficult to implement in a replicated environment. After all, you can just run that SELECT on a nearby replica. It’s only INSERT/UPDATE/DELETE/CREATE/DROP that cause problems, because SQL comes with the expectation that those operations occur instantly upon a single global state.

Add to the list of problematics queries sub-SELECTs, JOINs and I’m not sure what remains can still be called SQL.

Also a replicated system is not necessarily equivalent to a sharded system where implementing even the simplest forms of SELECT becomes more difficult.

While from an adoption point of view (including developers’ familiarity with SQL, tooling support, existing expertise), supporting SQL makes a lot of sense, there are too many problems to be solved until it would get to a decent level. All these limitations would just be frustrating to everyone.

Sometimes it’s much better to start with a clean solution and determine over time if an integration/standard is emerging. Most practical and long lived standards out there are coming from real-live battle proven scenarios/experience.

Original title and link: NoSQL vs SQL, Why Not Both? (NoSQL databases © myNoSQL)

via: http://www.cloudbook.net/resources/stories/nosql-vs-sql-why-not-both