Ever since SQL-89 was adopted as the first SQL standard, SQL aimed to be just that — the standardized, generic, nonprocedural, vendor-independent language of relational databases. It did succeed — to a certain extent — and the newest release of the SQL:2003 standard brings this promise a step closer to reality.
Unlike many popular programming languages (
C++, Java, Visual Basic, and
C#, to mention just a few), SQL was designed to work with sets of data and is explicitly non-procedural. That means that the features one takes for granted in any other programming language — control flow statements (
IF...THEN), looping constructs (
FOR...NEXT), and the like — were completely excluded.
SQL was designed for data storage, retrieval, and manipulation, and as such, it was tightly coupled with the database management system (DBMS) —it neither exists outside the DBMS nor can it be executed without it. All one has to do is to submit a query to a DBMS and receive results in some client program — either actual data from the database or status results of a task (such as inserting or deleting records).
In contrast to programming-style variables manipulation, inserting, updating, and retrieving data are set-based procedures. SQL statements operate on datasets, and although an operation itself might take a long time to complete, from the SQL programmer's point of view, it does not really have any flow (to be sure, the engine that ...