Història i evolució del SQL
D'on ve SQL?
A finals dels anys 60, IBM estava investigant com gestionar grans volums de dades de manera estructurada. Edgar F. Codd, matemàtic britànic treballant als laboratoris IBM, va publicar el 1970 l'article "A Relational Model of Data for Large Shared Data Banks", que definia formalment el model relacional: dades organitzades en taules, operades amb l'àlgebra relacional.
El problema era que l'àlgebra relacional, tot i ser formalment poderosa, no era accessible per a usuaris finals. IBM necessitava un llenguatge pràctic que permetés fer les mateixes operacions d'una forma llegible. Així va néixer el projecte System R (1973–1979), i el seu llenguatge associat: SEQUEL (Structured English Query Language), dissenyat per Donald Chamberlin i Raymond Boyce.
El nom va haver de canviar a SQL per raons de marca registrada, però la filosofia es va mantenir: un llenguatge declaratiu que descriu què vols obtenir, no com obtenir-ho.
AC0372/03/01 — Miniactivitat
RA1 · CA1.2, CA1.4
Busqueu l'article original de Codd (1970) i llegiu el resum. Quins problemes dels sistemes de fitxers de l'època intenta resoldre el model relacional?
La guerra dels SGBD i l'estandardització
El 1977, Larry Ellison va llegir l'article de Codd i va fundar Relational Software Inc. (avui Oracle). El 1979, Oracle va llançar el primer SGBD comercial basat en SQL, fins i tot abans que IBM publiqués el seu propi producte (DB2, 1983).
Davant la proliferació de dialectes incompatibles entre fabricants, es van iniciar els treballs d'estandardització:
- 1986 — SQL-86 (SQL1): El primer estàndard ANSI/ISO. Molt bàsic: SELECT, INSERT, UPDATE, DELETE, CREATE TABLE. Sense joins explícits, sense integritat referencial.
- 1989 — SQL-89: Petita revisió que va afegir la clau forana (
FOREIGN KEY) i integritat referencial bàsica.
La taula cronològica completa:
| Versió | Any | Aportacions principals |
|---|---|---|
| SQL-86 | 1986 | Base: SELECT/INSERT/UPDATE/DELETE, CREATE TABLE |
| SQL-89 | 1989 | FOREIGN KEY, integritat referencial |
| SQL-92 | 1992 | JOINs explícits, subconsultes, CASE, tipus de dades ampliats, ALTER TABLE |
| SQL:1999 | 1999 | Triggers, procediments emmagatzemats, expressions regulars, tipus de dades definits per l'usuari, suport a objectes |
| SQL:2003 | 2003 | Window functions (OVER, PARTITION BY), seqüències (SEQUENCE), XML bàsic, MERGE |
| SQL:2006 | 2006 | Integració XQuery/XML |
| SQL:2008 | 2008 | TRUNCATE, FETCH/OFFSET (paginació estàndard), triggers millorats |
| SQL:2011 | 2011 | Taules temporals (temporal tables), versionat de files per temps |
| SQL:2016 | 2016 | Suport JSON natiu (JSON_VALUE, JSON_QUERY, JSON_TABLE) |
| SQL:2019 | 2019 | Consultes sobre grafs multidimensionals (MDA) |
| SQL:2023 | 2023 | Millores JSON, funcions de propietat de grafs, ANY_VALUE |
SQL:1999 és el salt qualitatiu
Si hagués de triar una versió com a punt d'inflexió, seria SQL:1999: va transformar SQL d'un llenguatge de consulta bàsic a un sistema complet amb lògica procedimental. La majoria del que feu dia a dia ve d'aquesta versió o posteriors.
Dialectes: la realitat de la incompatibilitat
L'estàndard SQL existeix, però cap motor l'implementa completament ni de forma idèntica. Cada fabricant afegeix extensions pròpies i no implementa parts de l'estàndard que no li interessen. Això genera dialectes que comparteixen el 80% de la sintaxi però divergeixen en els detalls que importen:
| Característica | PostgreSQL | MySQL/MariaDB | SQL Server | Oracle |
|---|---|---|---|---|
| Autoincrement | SERIAL / GENERATED ALWAYS AS IDENTITY |
AUTO_INCREMENT |
IDENTITY(1,1) |
GENERATED ALWAYS AS IDENTITY / SEQUENCE |
| Paginació | LIMIT n OFFSET m |
LIMIT n OFFSET m |
OFFSET m ROWS FETCH NEXT n ROWS ONLY |
FETCH NEXT n ROWS ONLY |
| Concatenació | \|\| o CONCAT() |
CONCAT() |
+ o CONCAT() |
\|\| o CONCAT() |
| Data actual | CURRENT_DATE / NOW() |
CURDATE() / NOW() |
GETDATE() / SYSDATETIME() |
SYSDATE / CURRENT_DATE |
| Text variable | VARCHAR(n) |
VARCHAR(n) |
VARCHAR(n) / NVARCHAR(n) |
VARCHAR2(n) |
| Booleà | BOOLEAN |
TINYINT(1) |
BIT |
No existeix (usen NUMBER(1)) |
| Estàndard aproximat | SQL:2011+ | SQL:2003 parcial | SQL:2008+ parcial | SQL:2003 parcial |
No existeix el SQL portàtil
Un script SQL que funciona perfectament a PostgreSQL probablement necessitarà ajustos per executar-se a MySQL o SQL Server. En entorns professionals s'intenta escriure SQL estàndard quan es pot, però les divergències dels motors fan que rarament sigui possible al 100%. Per això en aquest mòdul treballarem sempre els 4 motors en paral·lel.
Suport als estàndards: quin motor és més "estàndard"?
PostgreSQL és, de llarg, el motor de codi obert que millor segueix l'estàndard SQL. La seva comunitat fa un seguiment explícit de quines parts de cada versió SQL:20xx han implementat. Oracle i SQL Server tenen suport sòlid però amb moltes extensions pròpies. MySQL/MariaDB ha millorat molt des de la versió 8.0 però històricament ha tingut buits importants (com la manca de window functions fins el 2018).
AC0372/03/02 — Miniactivitat
RA1 · CA1.6 · RA3 · CA3.8
Consulteu la documentació oficial de PostgreSQL i MySQL per veure quines parts de SQL:2023 suporten. Quines diferències trobeu?
Per què és important conèixer la història?
Quan trobeu una característica SQL que "no funciona" en un motor concret, sovint la resposta és que pertany a una versió de l'estàndard que aquell motor no ha implementat, o que l'ha implementat amb una sintaxi diferent. Conèixer l'evolució us permet:
- Entendre per què hi ha tanta sintaxi "alternativa" per fer el mateix.
- Saber quines característiques modernes podeu fer servir (window functions, JSON, CTE) i quines limitacions té cada motor.
- Llegir codi antic i entendre per què estava escrit d'aquella manera (per exemple, el
WHEREper fer joins en comptes delJOINexplícit de SQL-92). - Tenir criteri per escollir motor en un projecte nou.