- The “structured” part comes from the “S” in SQL; the full name is Structured Query Language. Structured programming was the “hotness” in programming language design in the late 1960s when SQL was initially proposed and designed, and while SQL itself doesn’t have a lot of classic “structured” mechanisms, the idea is that it allows “structured queries” as a query language versus the db access methods of the time that were basically “open a table or index, iterate through its records, qualify the rows in app logic, send rows that qualify to the user”. In this case the logic for the “database query” was a potentially quite complex chunk of application code that may or may not be “structured”.
- The “non-procedural” part is because SQL itself is “declarative”. You specify what you want to fetch with your SELECT-list, the tables that have the records in your FROM, and what will qualify with logic in your WHERE or JOIN ON clauses, with more directives as to how the answer should come back in stuff like GROUP BY, ORDER BY, DISTINCT, etc. You don’t specify how the query is to be answered by the DB engine; that’s up to the Query optimizer (and even optimizer hints are rather high-level “specifications” as to how a query is to be answered).
If SQL was “procedural”, you’d do stuff like “open table; load to cache; fetch row from table, if it’s a row I want, give, it, otherwise move on, etc”.
Since this type of logic *can* be useful in code that runs in a DB engine, Stored procedureswere invented to add procedural elements to client-side data access. However, SP language is considered to be a separate language from SQL itself.
Article by Greg Kemnitz