Speed up your development and test cycles with fully automated data delivery, view a 10 minute demo, brought to you in partnership with Delphix.
Got an email with links about NoSQL. Links like "Going NoSQL with MongoDB
This -- like many such articles -- includes the phrase "the NoSQL
movement" as if there's something new going on. Thank goodness Ted
Neward includes quotes around "new". This isn't new. And doubly good,
Neward doesn't use words like "excitement".
folks like to link to http://en.wikipedia.org/wiki/NoSQL. This is
misleading, of course, since avoiding SQL isn't new or even that
interesting. If you're going to treat avoiding SQL specially, then you
should have a NoProceduralProgramming, NoFunctionalProgramming,
NoAssembler, NoShellScript and NoHTML movements, also.
Why stop there? Why not have a NoDumbAssArchitecture movement, too?
-- I guess -- you've been solving all data management problems with a
relational database. I guess when you discover that you don't have to
use the hammer, then it's exciting to see that everything isn't simply a
If avoiding the hegemony of SQL
seems important, or even interesting, perhaps you've been living in a
cave. Seriously. The file system has always been there and has always
worked nicely for lots of problems. My 2002-era Ralph Kimball Data
Warehouse Toolkit books are very clear that large, high-volume data
warehouses are mostly flat files. Data marts are SQL databases suitable
for ad-hoc SQL queries. But the RDBMS isn't always the best place for
large volumes of data.
NoSQL isn't new or even very interesting.
you're an architect, but you're not looking at alternatives to the
RDBMS -- and running benchmarks to compare the choices -- you're not
really doing architectural work. You're probably a glorified programmer
and should consider working in a place that doesn't stifle you by
imposing a "one world -- one architecture" viewpoint.
you're a manager and think that "everything in SQL" is a risk-reducer,
you need to actually talk to your people. If you think that your
people's skills are limited to SQL, you're doing your team (and your
customers) a disservice. Consider a skill upgrade of your own. Your
team can learn other non-RDBMS technologies. Perhaps you should stop
If you're a DBA and you know --
for a fact -- that the relational database is perfect and complete, you
should perhaps pause a moment and consider things the relational
databases don't do well. Graph-theory problems and hierarchies require
fairly complex workarounds. Even a many-to-many relationship requires
this extra association table. Perhaps those things are the signs of
force-fitting data into the RDBMS model.
Learn how test data on demand can lead to faster application development, read the IDC white paper, brought to you in partnership with Delphix.