10 things never to do with a relational database (The data explosion demands new solutions, yet the hoary old RDBMS still rules. Here’s where you really shouldn’t use it) by Andrew C. Oliver.
From the post:
I am a NoSQLer and a big data guy. That’s a nice coincidence, because as you may have heard, data growth is out of control.
Old habits die hard. The relational DBMS still reigns supreme. But even if you’re a dyed-in-the-wool, Oracle-loving, PL/SQL-slinging glutton for the medieval RAC, think twice, think many times, before using your beloved technology for the following tasks.
[ If you aren’t going to use an RDBMS, which freaking database should you use? | See InfoWorld’s comparative review of NoSQL databases. | Keep up with the latest developer news with InfoWorld’s Developer World newsletter. ]
If you guessed this post is from InfoWorld and that it’s rather ranty, you are right on both counts.
Andrew’s 10 things:
- Search
- Recommendations
- High-frequency trading
- Product cataloguing
- Users/groups and ACLs
- Log analysis
- Media repository
- Classified ads
- Time-series/forecasting
Andrew ducks and covers in his conclusion with:
Can you use the RDBMS for some or many of these? Sure — I have and people continue to. However, is it a good fit? Not really. I expect the cranky old men to disagree, but tradition alone is not a good reason to stick with the old way of doing things.
If you disagree with his assessment, you are by definition a “cranky old man,” and no one wants to be seen as a cranky old man.
Being a “cranky old man,” the label doesn’t sting so I feel free to disagree. 😉
Andrew is right that tradition alone isn’t “a good reason to stick with the old way of doing things.”
On the other hand, because something is new or venture capitalists have parted with cash, isn’t a reason to find a new way of doing things.
Your requirements aren’t only technical questions but questions of IT competence to deploy a new solution, training of staff to use a new solution, costs of retraining and construction, and others.
Ignoring the non-technical side of requirements is a step toward acquiring a white elephant to sleep in the middle of your office, interfering with day to day operations.