SQL survives murder attempt by mutant stepchild
World says 'No' to NoSQL
Open...and Shut Silicon Valley likes nothing more than to fetish the Next Big Technology Trend, be it cloud or NoSQL or scripting languages. The problem is that the real world moves much more slowly, and has very different considerations fueling its technology decisions. Perhaps nowhere is this clearer than in the technology media's infatuation with NoSQL, even as the world plods along with SQL.
I was reminded of this by Redmonk analyst Stephen O'Grady, who nicely shows that far from rendering SQL obsolete, the NoSQL crowd actually finds itself adopting SQL's query languages. As O'Grady notes: "The category might self-identify with its explicit rejection of the industry’s original query language, but the next step in NoSQL’s evolution will be driven in part by furious implementations of SQL’s children."
Additionally, whatever its Oedipal desire to kill off its father, NoSQL remains a tiny blip in the overall datastore universe. Why? For one thing, SQL is much easier to learn, as O'Grady also points out. Google and its ilk are in furious bidding wars to buy the best tech talent the world has to offer. The mainstream enterprise can't compete with that, and ends up with mainstream engineers.
SQL v MapReduce job growth (source: Indeed.com (via Stephen O' Grady))
Those engineers know SQL. They generally don't know NoSQL variants like Cassandra, MongoDB, etc. This isn't to say that NoSQL will never win. But it is to suggest that technology transformations take a lot longer than the time needed to write about them.
Consider Java. It has taken a beating in the past few years, particularly in the press, which warmed to PHP and other scripting languages. Those nouveaux riche languages were supposed to kill off Java long ago, but that hasn't happened. Java (and its Microsoft kissing cousin, .Net) remains the lifeblood of enterprise IT. It's not sexy, but it remains a powerful programming language that is easily accessible to a large population of programmers.
And for as much as I talk up the chances for the mobile web to displace Apple's iOS, as more developers look to the browser to solve cross-platform woes in mobile, it's clear that Apple has pulled off a Microsoft-like developer coup. Microsoft didn't become the desktop king and a strong contender in servers through anti-competitive tying arrangements. No, Microsoft became a technology behemoth by relentlessly lowering the skills bar for application developers and IT administrators. Unix and other competitors were comparatively hard, if more secure/powerful/whatever. Microsoft was easy.
And so Microsoft won. Apple has invested a huge amount of time, thought, and money into making iOS development Windows-esque in its ease. The tooling for iOS is excellent. It's therefore easy for developers to embrace iOS as their preferred platform, regardless of Apple's market share (which happens to be quite strong). For the NoSQL crowd, to get beyond Twitter, Google, and other geek elites, there needs to be equal emphasis on making the tooling simple. Sure, some developers will invest the time and attention necessary to learn CouchDB because they absolutely need its functionality to solve a given business problem.
But the vast majority won't. Most people can't afford to be overly passionate about technology. This is what the open-source crowd missed for years, myself included, as we raged against the Microsoft machine while pragmatism kept the world buying Microsoft, Oracle, etc. Most developers aren't looking to start a revolution. Most just need to get things done for their respective employers, so they can afford cable TV and food for their families.
Yes, it's boring. But it's also true. ®
Matt Asay is senior vice president of business development at Strobe, a startup that offers an open source framework for building mobile apps. He was formerly chief operating officer of Ubuntu commercial operation Canonical. With more than a decade spent in open source, Asay served as Alfresco's general manager for the Americas and vice president of business development, and he helped put Novell on its open source track. Asay is an emeritus board member of the Open Source Initiative (OSI). His column, Open...and Shut, appears twice a week on The Register.
Such a blindingly obvious conclusion that it almost didn't need to be said. Almost.
Every so often, someone needs to point out how much of an echo chamber Silicon Valley is, and the tech reporting to go with it.
The real world of enterprise IT is a dull place of low expectations and glacial change.
I'll accept that the relational model does not alway map well to all tasks
but (as you point out) it maps DAMN well to a few tasks. the problem I'm seeing at the moment, is that all this non-relational hype is sometimes (but not necessarily always) just a cover for poor design.
Proper relational databases (sit down MySQL, you don't get any credit here. The lack of proper enforcement of relations in MySQL is IMNSHO one of the biggest issues this is a backlash against. MySQL is all the disadvantages of relational DBs, with none of the benefits.) means the DB is actually checking the data for you. Did some yahoo try to say John Smith drives a cat to work? Well "cats" are not in SillyDB.AutoMfgs, so a PROPER relational DB refuses to add it.
I've done some experimenting with redis, and it is nice for some things (session data is a great example), but for many things the advantages of relational are really hard to ignore.
mine the one with a PostgreSQL copy in the pocket
Once you start using InnoDB...
...the benefits of MySQL go away. With full relational constraints imposed, it's slower than Postgres. Not to mention that "relational constraints" in the MySQL world doesn't necessarily mean the same thing it does in real databases. Truncation (i.e. modifying data) rather than raising an error is the norm in the MySQL way of thinking. Yes, there's "strict mode" but that's enforced client side, not server side. Wanna dump some crap in your database? Turn off strict mode and have a ball. Or use "INSERT IGNORE".
Triggers? Make me laugh. Constraint checking? "Parsed but ignored". Transactional DDL? Nope. Transaction locking behaves "oddly" (but, I'll grant you, predictably). Inserting nulls into non-null fields? Check.
I could go on. I usually do. Facepalm because that's what MySQL is.