While computing has changed radically over the past forty years, relational databases have remained fundamentally unchanged.
In the ’70′s, when you were building a banking application, you got to use the new relational database technology if your problem was sufficiently important, and warranted the huge expense. If not, you continued to write a COBOL application and manage your data files yourself.
Future users of large data banks must be protected from having to know how the data is organized in the machine (the internal representation).
Edgar F. Codd, Communications of the ACM, Volume 13, Number 6, June, 1970
Edgar Codd’s statement about the need for encapsulation of data and the need to isolate the internal representation from the application is still as valid today, as it was in 1970.
Activites of users at terminals and most application programs should remain unaffected when the internal representation of data is changed and even when some aspects of the external representation are changed.
Mainframes gave way to Mini’s and Super Mini’s, then we had Client-Server, and now, forty years later, we have virtualization and the cloud.
Yet, databases have largely remained the same!
Yes, we now have MPP databases (mostly for analytics), we have alternate storage layouts (rows, columns, hybrids), and we are now seeing a rapid increase in the number of special purpose databases.
But, the traditional Relational Database has remained the SMP database, featuring ACID, the SQL language, and bringing with it forty years of baggage.
The environment in which Relational Databases are used today, the kinds of data that are being processed, the kinds of workloads that these databases must face, and most importantly, the volumes of data that are being processed have changed dramatically over the past forty years. Yet, general purpose relational databases have remained fundamentally unchanged over this period of time!
Add new comment