By Allen G. Taylor

The first thing to understand about SQL is that SQL isn’t a procedural language, as are Python, C, C++, C#, and Java. To solve a problem in a procedural language, you write a procedure — a sequence of commands that performs one specific operation after another until the task is complete. The procedure may be a straightforward linear sequence or may loop back on itself, but in either case, the programmer specifies the order of execution.

SQL
Solving problems using SQL.

SQL, on the other hand, is nonprocedural. To solve a problem using SQL, simply tell SQL what you want (as if you were talking to Aladdin’s genie) instead of telling the system how to get you what you want. The database management system (DBMS) decides the best way to get you what you request.

All right. You were just told that SQL is not a procedural language — and that’s essentially true. However, millions of programmers out there (and you’re probably one of them) are accustomed to solving problems in a procedural manner. So, in recent years, there has been a lot of pressure to add some procedural functionality to SQL — and SQL now incorporates features of a procedural language: BEGIN blocks, IF statements, functions, and (yes) procedures. With these facilities added, you can store programs at the server, where multiple clients can use your programs repeatedly.

To illustrate what is meant by “tell the system what you want,” suppose you have an EMPLOYEE table from which you want to retrieve the rows that correspond to all your senior people. You want to define a senior person as anyone older than age 40 or anyone earning more than $100,000 per year. You can make the desired retrieval by using the following query:

SELECT * FROM EMPLOYEE WHERE Age > 40 OR Salary > 100000 ;

This statement retrieves all rows from the EMPLOYEE table where either the value in the Age column is greater than 40 or the value in the Salary column is greater than 100,000. In SQL, you don’t have to specify how the information is retrieved. The database engine examines the database and decides for itself how to fulfill your request. You need only specify what data you want to retrieve.

A SQL query is a question you ask the database. If any of the data in the database satisfies the conditions of your query, SQL retrieves that data.

Current SQL implementations lack many of the basic programming constructs that are fundamental to most other languages. Real-world applications usually require at least some of these programming constructs, which is why SQL is actually a data sublanguage. Even with the extensions that were added in 1999, 2003, 2005, 2008, and 2011, you still have to use SQL in combination with a procedural language (such as C++) to create a complete application.

You can extract information from a database using SQLin one of two ways:

  • Make an ad hoc query from your keyboard by just typing an SQL statement and reading the results from the screen. Queries from the keyboard are appropriate when you want a quick answer to a specific question. To meet an immediate need, you may require information that you never needed before from a database. You’re likely never to need that information again, either, but you need it now. Enter the appropriate SQL query statement from the keyboard, and in due time, the result appears on your screen.
  • Execute a program that collects information from the database and then reports on the information either onscreen or in a printed report. Incorporating an SQL query directly into a program is a good way to run a complex query that you’re likely to run again in the future. That way, you can formulate a query just once for use as often as you want.

A (very) little SQL history

SQL originated in one of IBM’s research laboratories, as did relational database theory. In the early 1970s, as IBM researchers developed early relational DBMS (or RDBMS) systems, they created a data sublanguage to operate on these systems. They named the pre-release version of this sublanguage SEQUEL (Structured English QUEry Language). However, when it came time to formally release their query language as a product, they found that another company had already trademarked the product name “Sequel.” Therefore, the marketing geniuses at IBM decided to give the released product a name that was different from SEQUEL but still recognizable as a member of the same family. So they named it SQL, pronounced ess-que-ell. Although the official pronunciation is ess-que-ell, people had become accustomed to pronouncing it “Sequel” in the early pre-release days and continued to do so. That practice has persisted to the present day; some people will say “Sequel” and others will say “S-Q-L,” but they are both talking about the same thing.

The syntax of SQL is a form of structured English, which is where its original name came from. However, SQL is not a structured language in the sense that computer scientists understand that term. Thus, despite the assumptions of many people, SQL is not an acronym standing for “structured query language.” It is a sequence of three letters that don’t stand for anything, just like the name of the C language does not stand for anything.

IBM’s work with relational databases and SQL was well known in the industry even before IBM introduced its SQL/DS relational database (RDBMS) product in 1981. By that time, Relational Software, Inc. (now Oracle Corporation) had already released its first RDBMS. These early products immediately set the standard for a new class of database management systems. They incorporated SQL, which became the de facto standard for data sublanguages. Vendors of other relational database management systems came out with their own versions of SQL. Typically, these other implementations contained all the core functionality of the IBM products, extended in ways that took advantage of the particular strengths of their own RDBMS product. As a result, although nearly all vendors used some form of SQL, compatibility between platforms was poor.

An implementation is a specific RDBMS running on a specific hardware platform.

Soon a movement began, to create a universally recognized SQL standard to which everyone could adhere. In 1986, ANSI (the American National Standards Institute) released a formal standard it named SQL-86. ANSI updated that standard in 1989 to SQL-89 and again in 1992 to SQL-92. As DBMS vendors proceed through new releases of their products, they try to bring their implementations ever closer to this standard. This effort has brought the goal of true SQL portability much closer to reality.

The most recent full version of the SQL standard is SQL:2016 (ISO/IEC 9075-X:2016).. Every specific SQL implementation differs from the standard to a certain extent. Because the complete SQL standard is comprehensive, currently available implementations are unlikely to support it fully. However, DBMS vendors are working to support a core subset of the standard SQL language. The full ISO/IEC standard is available for purchase, but you probably don’t want to buy it unless you intend to create your own ISO/IEC SQL standard database management system. The standard is highly technical and virtually incomprehensible to anyone other than a computer language scholar.