In June 1970, Dr. E.F. Codd published the seminal paper, “A Relational Model of Data for Large Shared Data Banks,” for the ACM. This paper laid the foundation of relational databases, and Codd’s model was accepted as the definitive model for relational database management systems across research institutes around the world.
In 1974, at IBM’s San Jose Research Center, Donald Chamberlin and Raymond Boyce invented Structured English Query Language (SEQUEL) to implement Codd’s model in a System/R project that was aimed at developing the first SQL implementation. It also seeded IBM’s relational database technology.
Over the next three years, SEQUEL became SQL (still pronounced “sequel,” but some people spell it out as S-Q-L). IBM conducted the beta testing of System/R at customer test sites and demonstrated the usefulness and practicality of the system. As a result, IBM developed and sold commercial products that implemented SQL based on their System R prototype, including SQL/DS, introduced in 1981, and DB2 in 1983.
Meanwhile, in 1979, Relational Software introduced the first commercially available implementation of SQL, called Oracle Version 2. The company later changed its name to match its flagship product. Also, several other vendors such as Ingres (based on the Ingres project led by Michael Stonebraker and Eugene Wong at the Univ. of California, Berkeley during late 1970s) and Sybase introduced database products using SQL.
For the past three decades, SQL has been accepted as the standard RDBMS language. With the veracity of Moore’s law and the continuous research and upgrades on SQL implementations by some of the top vendors in RDBMS arena, SQL has come a long way.
There are three key reasons for the longevity of SQL:
Simplicity. SQL is simple. It is simple to learn and implement. It can be used for data definition, data manipulation and data control. It is declarative. You tell it what you want using simple language constructs. While this was a handicap, programming extensions such as PL/SQL and Pro*C bridged the gap and provided the ability to build programming logic too.
Mathematical foundation. SQL is built on concepts such as relational algebra and tuple calculus. This enabled its success in all databases that supported relational models to store, retrieve and manipulate data. Even today, a vast majority of data of businesses across the world resides on relational databases that support SQL.
Multi-vendor support. SQL has been implemented by many vendors, and even though there were issues related to the standardization of SQL, the fundamental principles and constructs remained universal. This encouraged database users at all levels to leverage the strengths of SQL.
The power of SQL increased tremendously over these three decades. While the initial versions of relational databases lacked support for basic concepts such as referential integrity, the latter versions offered support for several advanced concepts such as two-phase commits, partitioned tables and object orientation, to name a few. Because of this evolution, SQL emerged as the de facto standard for relational databases.
SQL came across several challenges during these three decades. One of them was unpredictable scalability, which challenged not only the product engineering community during the Internet era, but also end users and other stakeholders. RDBMS implementations that shined during the late 1990s started facing scalability and performance issues when applications and products migrated to the Web.
Databases had to store long text strings, images and other types of data to support Web-based products and applications. Also, the number of simultaneous users became unpredictable and seasonal. Clustering and load-balancing solutions provided little relief. Gradually, database administrators and system administrators found ways to handle such issues.
These times raised expectations on RDBMS (and hence SQL), which led to issues related to user satisfaction. Product teams wanted to find alternate ways to access data. Frameworks that supported object-relational mapping came into play. Meanwhile the need for processing and mining the data available in social networking forums and other collaboration platforms on the Internet resulted in new disciplines such as “Sentimental Analysis.” Also, paradigms such as virtualization and software-as-a-service opened up a new arena called cloud computing.
What about NoSQL?
The NoSQL movement began in 1998, and it supported database implementations that are non-relational data stores of several categories, such as document stores, graph databases, key-value stores and multi-valued databases. While there are several flavors of NoSQL implementations such as Oracle’s Berkeley DB, Google’s BigTable, Apache’s Cassandra and Amazon’s SimpleDB, SQL continues to thrive today.
In his blog titled “The NoSQL discussion has nothing to do with SQL,” Michael Stonebraker articulates the performance overheads on OLTP systems, and he provides his views on optimizing performance using concepts such as horizontal partitioning. He concludes that resolving scalability and performance issues are possible either in a SQL context or some other context.
It is evident that SQL and the NoSQL movement are complementary. RDBMS and SQL implementations will continue to thrive in ecosystems that require OLTP support on relational data stores.
However, a critical challenge in front of the software industry has become visible with the plethora of NoSQL database implementations and the waves of evolutionary ideas and concepts in implementing Cloud Databases. Years ago, our industry made considerable progress in standardizing SQL, and the success rate was not a perfect 10/10.
At present, are we even attempting to invent something similar to SQL for cloud databases? Or are we digressing with multiple approaches while increasing the risk of inducing issues related to data consistency, concurrency, integration and accuracy? Time alone will tell.
Raja Bavani heads delivery for MindTree’s Software Product Engineering group in Pune, India, and also plays the role of SPE evangelist.
