SQL at 40: Ready for Retirement?
February 26, 2010
Darned interesting write up in the Kellogg (formerly the Web log of the CEO of Mark Logic Corporation). The title caught my attention: “The Database Tea Party: The NoSQL Movement.” If you are struggling with your favorite 50-year old database technology, you will want to read Mr. Kellogg’s article. This comment sums up Kellogg’s position:
If you’re struggling with an RDBMS on a given application problem you shouldn’t say: we need an open source, NoSQL type thing. You should say: we need to look at relational database alternatives. Those alternatives include a open source database projects (e.g., MongoDB, CouchDB) and key-value stores (e.g., Hadoop), but they also include commercial software offerings such as specialized DBMSs like Streambase (for real-time streams), Aster (for analytics on big data), and MarkLogic (for semi-structured data). Don’t throw out the commercial-software-benefits baby with the RDBMS bathwater.
I have written about the challenges SQL poses. I want to point out that even firms with non-RDBMS solutions * can use * SQL for certain tasks. I heard one Googler several years ago mention that MySQL was a useful tool. That may have changed now, but I have a couple of RDBMS files that work just fine. The “fine” is the key word because I am not pushing beyond the capabilities of the 40-year old invention of Dr. Codd.
You don’t see too many 40-year-olds athletes in the Olympics or professional sports. Why not take the same pragmatic approach to data management?
Stephen E Arnold, February 25, 2010
The addled goose has been paid by Mark Logic Corporation to give talks at the firm’s user meetings. I was not paid to write this news item, however. Next time I am in San Francisco I will try to get a taco out of this company’s engineering department.
Comments
- Subscribe to Beyond Search
Feature archive
News archive
-
However, I have spent vaste time in the past to walk through and set up databases called relational.
As a matter of fact these RDBMS were just a sort of spreadsheet improvement, with impressive benchmark results for marketing purpose only.
Now we realize that the king is naked and very costly, providing with neither profit nor usage benefit to those who have contributed to its fame.
This was a step to understand that something was to invent in order to fit with real needs.
Not really a pifall, just a necesqsary test case to explore and then give up after.
It’s just like that the flint face the Swiss army knife
RDBMS’s are not going away anytime soon. The tool has to fit the job and relational databases fill an enormous space where architectures call for replication, queuing, and complex, distributed transaction processing. Pure object databases also have their space but for many applications that do not require the persistance of instance data, or where a relational model just can’t suffice, creating a simple relational model is easy, efficent and high performance.
Part of the problem is that new programmers do not understand relational database technology from an architectural viewpoint and how to apply it. I believe that, because of the explosion of new technologies, core competencies in areas such relational database technology are neglected. They are not properly taught. Viewing relational databases as a “spreadsheet improvement” anecdotally supports my point. I see this lack of training in the code and database structures that are being created by younger coders; no understanding of indexes, PK/FK relationships, transaction management, data modeling and then poorly constructed SQL to top it off. This stuff isn’t rocket science either.
These problems leads to the thinking that relational techology is dead. Relational technology is highly polished. It has been commoditized a long time ago so there is very little new to get excited about. That doesn’t mean that it is not a great fit for many (if not most) applications.