We're learning that most languages are classified as either of the two, "relation based" or "high level".
Those concepts are orthogonal. "Relation-based" means that the language's semantics are based on the concept of a relation, that is, a many-to-many association between two sets (relations are the mathematical foundation behind SQL tables). "High-level" means that the language contains a lot of abstractions that hide much of the underlying technical details (such as memory locations, CPU registers, disk access, bitwise operations, etc.). SQL is certainly relation based, as its main purpose is to describe relational data and operations upon it. SQL is also fairly high level; it does not provide any means to access bytes on disk directly, and it doesn't tell you any details about how it stores its data (at least standard SQL doesn't; most vendors provide extensions to the standard that can give you quite some information, but that's beside the point).
In fact, there are many more axes along which programming (and data) languages can be classified; a particularly interesting one is declarative vs. imperative. Declarative languages describe what something is; imperative languages describe how to do something. The DDL part of SQL is mostly declarative, despite the imperative-looking keywords ("
CREATE TABLE", "
DROP DATABASE", etc.), and even the data manipulation part (
DELETE) is still pretty declarative. A very interesting property of SQL is that it is not Turing complete: you cannot write an unbounded loop in plain standard ANSI SQL.
Functional programming centers around a few core ideas:
- functions are first-class citizens (that is, they can be used as values, as inputs to other functions, and as output from other functions)
- higher-order functions (functions that operate on functions, or functions that return functions)
- purity (a pure function is one that has no side effects; a pure function cannot do any I/O, it cannot read nor modify any global state, and it cannot take non-const reference arguments. Pure functions are especially interesting because they will always produce the same output given the same inputs)
SQL certainly doesn't revolve around functions as the main tool for modeling things, but it does somewhat embrace the purity idea - the same query run on the same database will yield the same result, every time (except for ordering). Calling SQL a 'functional' language is a bit of a stretch though IMO.