1. Origins and Background

SQL was born out of early explorations into relational databases during the 1970s. In 1970, E. F. Codd published “A Relational Model of Data for Large Shared Data Banks”, introducing the relational model, which proposed that data should be represented as tables and queried through mathematical set operations.

Traditional file systems and early databases typically relied on program code to read data from disk into memory and then process it record by record. This approach suffered from two fundamental problems:

  • Tight coupling between data and programs: applications had to understand the physical storage details of the data.
  • Poor reusability of query logic: development was complex and maintenance was costly.

The relational model proposed:

  • Using tables (relations) as the abstract data structure;
  • Making set operations and predicate filtering the core query mechanism;
  • Letting the system handle storage access and query optimization, so that users only need to describe what they want.

2. The Goals of SQL

SQL was designed to address two core challenges in applying the relational model in practice:

  • Data independence: freeing users from having to care about physical storage, index structures, or file organization;
  • Declarative querying: allowing users to describe the results rather than the execution steps, and letting the database system determine the optimal execution plan.

At the same time, SQL needed to satisfy the following requirements:

  • Support the definition, modification, and control of structured data;
  • Support complex queries involving joins, aggregation, grouping, and sorting;
  • Support transactions, concurrency control, and data integrity;
  • Support multi-user shared access and security control.

3. Why We Needed SQL

From a problem-solving perspective, SQL emerged because there was a need for a unified, portable, and easy-to-use way to access relational data:

  • Applications should not write direct disk access code;
  • Queries should resemble “asking the database a question” rather than “writing a traversal algorithm”;
  • The data model should be decoupled from programming languages so that schemas can evolve without breaking existing applications;
  • The database system should handle optimization so that the same query can execute efficiently across different environments.

In other words, SQL was not designed for writing programs — it was designed for expressing data requirements.

4. What Problems SQL Solved

4.1 Abstracting Storage and Access

SQL abstracts data through the relational model and table structures, hiding the underlying storage details. Developers only need to define schemas, constraints, and views without having to manage record formats or storage blocks.

4.2 Simplifying Query Expression

SQL is a declarative language. Users only need to describe the result they want:

  • SELECT specifies the columns;
  • FROM specifies the data sources;
  • WHERE specifies the filter conditions;
  • GROUP BY / ORDER BY construct aggregation and sorting.

This paradigm makes complex queries look like “finding the set of data that matches certain criteria,” rather than writing loops, index lookups, and join algorithms.

4.3 Shared, Multi-User Access

SQL was designed from the ground up for shared database systems, supporting concurrent access by multiple users, access control, and transactional consistency. It abstracts operations into categories such as DDL (Data Definition Language), DML (Data Manipulation Language), and DCL (Data Control Language), making permission and consistency management straightforward.

4.4 Optimization and Portability

Because users only specify what they want rather than how to get it, the database system is free to optimize the query. This separation allows the same SQL statement to run across different database management systems (DBMS), with each system choosing its own optimal execution plan.

5. The Lasting Value of SQL

The emergence of SQL marked a paradigm shift for databases — from “program-logic-driven data processing” to “data-driven declarative access.” It solved:

  • The coupling problem between data and programs;
  • The reusability and maintainability of queries;
  • Multi-user sharing and transactional consistency;
  • Automatic optimization and portability.

In conclusion, SQL exists to turn data access into descriptive querying, and to let the database system handle the underlying execution.