Els esquemes canvien. Sempre. Cal desar el telèfon dels clients, el VARCHAR(60) es queda curt, algú s'ha adonat que aquella columna estava mal anomenada, màrqueting vol una columna total a comandes per no recalcular-la a cada informe, i una regla de negoci que fins ara vivia al codi hauria de ser en un CHECK. La base de dades que vas crear a 05-01 i vas omplir a 05-02 no és un monument: és un organisme en producció que mutarà desenes de vegades.

ALTER TABLE és la instrucció que ho permet. La seva sintaxi s'aprèn en vint minuts. El que separa un professional d'un accident no és la sintaxi: és saber quines operacions bloquegen la taula i quines no, entendre que a PostgreSQL una migració es pot desfer amb ROLLBACK i a MySQL no, conèixer el patró que permet canviar un esquema sense aturar el servei, i acceptar la regla que regeix tota la indústria: cap canvi d'estructura s'escriu a mà en una consola de producció.

Aquesta lliçó cobreix les dues meitats, i tanca el mòdul.

⚠️ Avís de seguretat

ALTER TABLE és una operació destructiva i irreversible en els seus efectes sobre les dades. Un DROP COLUMN elimina una columna sencera i tot el seu contingut; un ALTER COLUMN TYPE pot truncar valors; un ADD CONSTRAINT pot rebutjar files existents.

• Executa tots els exemples sobre la teva base de dades de pràctiques (botigaverda), mai en producció.
• Fes una còpia de seguretat prèvia: pg_dump -U curs_sql -d botigaverda -f copia.sql.
• Treballa dins de BEGIN … ROLLBACK: a PostgreSQL el DDL és transaccional i ho pots desfer.
• En un sistema real, tot canvi d'esquema ha d'anar revisat pel responsable de la base de dades, provat abans en un entorn equivalent al de producció i aplicat com a migració versionada, mai a mà.

1. ALTER TABLE: el mapa d'operacions
2. ADD COLUMN, amb i sense DEFAULT
3. DROP COLUMN
4. RENAME COLUMN i RENAME TO
5. ALTER COLUMN TYPE i la clàusula USING
6. SET / DROP NOT NULL i SET / DROP DEFAULT
7. ADD / DROP CONSTRAINT, i la tècnica NOT VALID + VALIDATE
8. Què bloqueja la taula i què no
9. DDL transaccional: PostgreSQL davant de MySQL
10. El patró expand/contract
11. Migracions versionades
12. Què fer i què no fer en producció
13. Errors habituals i consells
14. Exercicis
15. Conclusió del mòdul

Les accions més habituals:

Un detall de sintaxi que estalvia molt de temps: diverses accions caben en una sola sentència, separades per comes. I això no és només elegància — és que la taula es bloqueja una vegada en lloc de N:

Avís sobre els objectes d'aquesta lliçó. clients.telefon, clients.newsletter i comandes.total són exemples puntuals: no formen part de l'esquema canònic de BotigaVerda i no apareixeran als mòduls següents. Recarrega botigaverda.sql en acabar.

(Recarrega botigaverda.sql abans de continuar: els exemples d'aquest apartat tornen a afegir les dues columnes de l'anterior, aquesta vegada una a una.)

La columna neix nul·lable i totes les files existents queden amb NULL. És instantani independentment de la mida de la taula: PostgreSQL només anota la columna nova al seu catàleg, sense tocar ni un sol byte de dades.

Les quinze files tenen FALSE. I aquí hi ha una de les millores més importants de PostgreSQL de l'última dècada:

Des de PostgreSQL 11, afegir una columna amb DEFAULT constant ja no reescriu la taula. Abans, aquesta operació recorria i reescrivia cada fila per gravar-hi el valor: en una taula de cent milions de files eren hores de bloqueig exclusiu — el cas d'estudi clàssic de "com tombar producció amb una línia d'SQL".

Ara PostgreSQL desa el valor per omissió al catàleg i el retorna "al vol" per a les files antigues, escrivint-lo físicament només quan aquelles files s'actualitzen per un altre motiu. L'operació passa d'hores a mil·lisegons.

L'excepció, que continua sent cara:

Si el DEFAULT no és constant —una funció aleatòria, un NOW() que ha de diferir per fila— cada fila necessita el seu propi valor i no hi ha cap drecera possible. La regla:

Nota de dialecte: MySQL 8 amb InnoDB permet ADD COLUMN amb ALGORITHM=INSTANT en molts casos (columna al final de la taula, sense canvi de format de fila); si no, reconstrueix. Oracle té una optimització equivalent des d'11g. SQLite afegeix columnes al final de manera barata però no permet afegir-les amb un DEFAULT no constant. SQL Server distingeix entre afegir una columna nul·lable (instantani) i una NOT NULL amb DEFAULT (instantani des del 2012 Enterprise, reescriptura a la resta d'edicions).

També és instantani: PostgreSQL no esborra les dades, marca la columna com a eliminada al catàleg i deixa de mostrar-la. L'espai es recupera quan cada fila es reescriu (per un UPDATE o per un VACUUM FULL).

Això té dues implicacions que convé conèixer:

1. La dada continua físicament en disc fins que es reescrigui la fila. Si la columna contenia informació sensible, un DROP COLUMN no és un esborrat segur.
2. L'operació és irreversible des d'SQL un cop confirmada. No hi ha UNDROP.

Si alguna cosa depèn de la columna (una restricció, una vista, un índex), DROP COLUMN falla:

Amb CASCADE s'endú per davant el que en depengui:

I amb això acabes de destruir la columna més important del catàleg i la seva restricció. CASCADE a ALTER TABLE mereix el mateix respecte que a DELETE.

Totes dues són purament de catàleg: instantànies, sense tocar dades, i reversibles amb un altre RENAME.

I totes dues són, en un sistema amb aplicacions connectades, de les operacions més perilloses que existeixen. El motiu no és tècnic: és que en l'instant en què confirmes el canvi, tot el codi que esmenta el nom antic deixa de funcionar:

Un ALTER TABLE de dos segons ha trencat l'aplicació sencera. I no hi ha finestra de transició: o el codi fa servir el nom vell, o fa servir el nou.

La regla: un RENAME en producció mai no es fa de cop. Es fa amb el patró expand/contract de l'apartat 10, o no es fa. I si el nom és lleig però funciona, moltes vegades la resposta correcta és deixar-lo lleig.

Desfem els dos canvis abans de continuar:

Ampliar la precisió d'un NUMERIC funciona directament, perquè tots els valors existents caben al tipus nou. El mateix passa en passar de VARCHAR(60) a VARCHAR(120) o a TEXT: PostgreSQL reconeix aquells casos com a compatibles a nivell binari i no reescriu res.

Reduir, en canvi, pot fallar:

I això és una bona notícia: PostgreSQL comprova totes les files abans d'aplicar el canvi, i si una sola no hi cap, avorta sense tocar res. Mai no trunca en silenci.

Nota de dialecte: MySQL, segons el seu mode SQL, sí que pot truncar en silenci en reduir un VARCHAR. Amb sql_mode a STRICT_TRANS_TABLES (el valor per omissió des de MySQL 5.7) dóna error; amb el mode relaxat, retalla el text i emet un avís que gairebé ningú no llegeix. És una de les diferències de comportament més perilloses entre motors.

Quan la conversió no és automàtica, PostgreSQL t'ho diu i t'ofereix la sortida:

Un intent directe de convertir el text a data:

USING rep una expressió que calcula el valor nou a partir de l'antic, fila a fila:

USING admet qualsevol expressió, no només conversions. Per exemple, per passar linies_comanda.descompte de fracció (0.10) a percentatge enter (10):

Tres avisos sobre ALTER COLUMN TYPE:

Falla si hi ha files amb NULL… llevat que a BotigaVerda tots els clients tinguin ciutat, que és el cas. Provem-ho amb una que sí que té nuls:

Les deu comandes web ho impedeixen, i correctament: aquell NULL significa alguna cosa (04-03).

L'operació inversa sempre funciona, perquè relaxar una restricció no pot invalidar mai dades existents:

Els valors per omissió funcionen igual, i són pur catàleg:

Canviar el DEFAULT no afecta les files existents. Només canvia el que s'omplirà a les insercions futures. És un error clàssic esperar el contrari.

Aquí es cobra la insistència de 05-01 a anomenar les restriccions: per treure'n una cal anomenar-la, i no pots anomenar el que no saps com es diu.

Funciona perquè cap dels 20 productes no té un cost superior al seu preu. Si n'hi hagués, PostgreSQL rebutjaria l'ALTER TABLE sencer:

Treure-la:

I les altres tres famílies:

Afegir un CHECK o una FOREIGN KEY obliga PostgreSQL a comprovar totes les files existents, i ho fa amb un bloqueig exclusiu. En una taula de deu milions de files això pot ser un minut llarg durant el qual ningú no pot llegir ni escriure.

La solució en dos temps:

Què fa exactament NOT VALID:

És a dir: NOT VALID et dóna la protecció cap al futur immediatament, i deixa la comprovació de l'històric per a un moment tranquil. És la tècnica estàndard per afegir restriccions a taules grans en producció.

I comprovar quines restriccions estan sense validar:

Desfem l'exemple:

Aquest és l'apartat que separa una migració innòcua d'una caiguda de producció.

PostgreSQL protegeix cada operació amb un nivell de bloqueig. El més agressiu és ACCESS EXCLUSIVE: mentre es manté, cap altra sessió no pot ni tan sols llegir la taula. Totes les consultes es queden esperant.

I ara el veritablement important, que gairebé ningú no explica:

Una operació "instantània" no és inofensiva si no aconsegueix el bloqueig.

Un ALTER TABLE ADD COLUMN triga un mil·lisegon… un cop ha obtingut l'ACCESS EXCLUSIVE. Si en aquell moment hi ha una consulta llarga llegint la taula, l'ALTER es posa a esperar. I mentre espera, PostgreSQL encua darrere seu totes les consultes noves, perquè els bloqueigs es concedeixen per ordre d'arribada.

Un ALTER TABLE d'un mil·lisegon acaba de deixar la taula inaccessible cinc minuts. La protecció estàndard:

Si en tres segons no aconsegueix el bloqueig, avorta amb canceling statement due to lock timeout en lloc de bloquejar la base. Es reintenta més tard. Posar lock_timeout a tota migració és una de les pràctiques més rendibles que existeixen.

Aquesta és una diferència crítica entre motors, i canvia completament com s'escriu una migració.

A PostgreSQL, el DDL és transaccional:

Com si no hagués passat mai. Els dos ALTER TABLE s'han desfet.

La conseqüència pràctica és enorme: a PostgreSQL pots embolcallar una migració de quinze passos en BEGIN … COMMIT i tenir la garantia que o s'aplica sencera o no s'aplica res. Si el pas 12 falla, l'esquema queda exactament com estava.

A MySQL i Oracle, cada sentència DDL confirma implícitament la transacció en curs. Si una migració de quinze passos falla al dotze, els onze primers ja estan aplicats i no hi ha manera de desfer-los. Per això en aquells motors tota migració necessita el seu script de reversió escrit a mà, i per això les eines de l'apartat 11 insisteixen tant en el concepte de down migration.

Si treballes amb MySQL, interioritza això: no existeix la xarxa de seguretat. Cada pas de la migració ha de ser reversible per si sol, i l'ordre importa moltíssim més.

Com es canvia un esquema sense aturar el servei.

El problema de fons: la base de dades i l'aplicació es despleguen per separat, i durant una estona conviuen la versió antiga i la nova del codi. Qualsevol canvi que trenqui una de les dues provoca errors. Un RENAME COLUMN, com has vist, trenca la versió antiga en l'instant en què es confirma.

Expand/contract (també anomenat parallel change) resol això descomponent el canvi en cinc fases, cadascuna compatible cap endavant i cap enrere:

La clau és que en cap moment no existeix un estat en què l'aplicació pugui fallar: entre la fase 1 i la 5, totes dues versions del codi funcionen.

BotigaVerda calcula el total de cada comanda sumant-ne les línies i afegint-hi els ports. És correcte (01-05 ho justificava: res d'agregats precalculats), però els informes del mòdul 4 repeteixen aquella expressió una vegada i una altra, i amb volum alt el cost es nota. Direcció demana una columna total desnormalitzada.

Fase 1 — Expand: afegir la columna, nul·lable.

Instantani, nul·lable, sense DEFAULT. El codi antic continua funcionant: no sap que la columna existeix i no la necessita.

Fase 2 — Doble escriptura. Es desplega una versió de l'aplicació que, a més de crear la comanda i les seves línies, omple total. Les comandes noves tenen valor; les antigues continuen a NULL. Cap canvi d'esquema en aquesta fase — és pur desplegament de codi.

Fase 3 — Backfill: omplir cap enrere.

Amb les eines d'aquest mòdul, sense subconsultes, en dos passos:

Fixa't en l'AND co.total IS NULL: fa l'UPDATE idempotent (05-03) i, sobretot, garanteix que el backfill no trepitja els valors que la fase 2 ja està escrivint en temps real. És el detall que converteix un backfill perillós en un de segur.

En una taula real el backfill es faria per lots —WHERE total IS NULL AND id BETWEEN 1 AND 10000, repetit— per no mantenir una transacció gegant bloquejant files.

Fase 4 — Canviar la lectura, i verificar.

Abans que els informes comencin a fer servir la columna nova, cal comprovar que coincideix amb el càlcul en viu:

(8 primeres de 20 files.)

I la comprovació global, que és la que de debò importa:

846,20 €: exactament la xifra canònica del mòdul 4 (727,95 € de producte + 118,25 € de ports). Vint comandes, cap sense omplir. El backfill és correcte.

En aquesta fase, el professional és deixar la comparació funcionant uns dies amb una alerta: si algun cop total deixa de coincidir amb la suma de les línies, és que la doble escriptura té un forat.

Fase 5 — Contract: consolidar i netejar.

Ara que totes les files tenen valor, la columna pot ser obligatòria. I es retira del codi el càlcul antic.

Queda un problema obert, i convé dir-ho amb claredat: comandes.total és un agregat precalculat i cal mantenir-lo sincronitzat. Si demà algú modifica una línia de comanda amb un UPDATE directe, total queda obsolet i ningú no se n'assabenta. Les tres solucions —un trigger que el recalculi, una vista materialitzada, o una columna generada si la fórmula visqués a la mateixa fila— són del mòdul 10. És exactament l'advertiment de 01-05, secció 8: desnormalitza amb mesures a la mà, i documenta com el mantindràs al dia.

El mateix patró, aplicat a un canvi de forma. Suposa que BotigaVerda hagués nascut amb una única columna nom_complet i volguessis separar-la:

Fixa't en el que mai no es fa: un RENAME COLUMN de cop, ni un DROP COLUMN abans que ningú no la llegeixi. Cada fase és reversible i cap no trenca la versió anterior del codi.

Tot l'anterior té un requisit previ que no és tècnic:

Un canvi d'esquema no és una ordre: és un fitxer versionat al repositori.

Un fitxer numerat, amb nom descriptiu, que conté un canvi d'esquema i (idealment) la seva reversió:

Una eina de migració manté a la mateixa base de dades una taula de control amb les migracions ja aplicades, i en arrencar aplica només les que falten, en ordre.

Per què això és innegociable:

Totes resolen el mateix problema i difereixen sobretot en si el canvi s'escriu en SQL o en el llenguatge de l'aplicació. Escriure'l en SQL pur (Flyway, Sqitch, golang-migrate) dóna control total sobre lock_timeout, NOT VALID i CONCURRENTLY; escriure'l en el llenguatge de l'aplicació (Alembic, Rails, Django) dóna portabilitat entre motors i reversió automàtica, al preu de perdre el control fi que necessiten les taules grans.

1. Una migració = un canvi. Si el fitxer fa cinc coses i la tercera falla en producció, no sabràs en quin estat ha quedat (i a MySQL, a més, no ho podràs desfer).
2. Sempre amb script de reversió. Encara que el teu motor tingui DDL transaccional, escriure el down t'obliga a pensar si el canvi és reversible. Moltes vegades descobriràs que no ho és —un DROP COLUMN no es desfà— i això és informació valuosíssima abans d'aplicar-lo.
3. Provada en un entorn igual al de producció. No al teu portàtil amb 20 files: en una còpia amb volum realista. Un ALTER COLUMN TYPE que triga 40 ms amb 20 files triga 40 minuts amb 40 milions.
4. Amb còpia de seguretat prèvia i verificada. I verificada significa restaurada alguna vegada, no "el cron diu que funciona".
5. Mai a mà a la consola de producció. Ni "només aquesta vegada", ni "és un canvi petit", ni "és urgent". El canvi que no és al repositori no existeix, i el pròxim entorn que es creï no el tindrà.

I un corol·lari que surt de la fase 2 de l'expand/contract: les migracions que trenquen la compatibilitat cap enrere s'han de partir en diverses. V003 afegeix la columna, V004 l'omple, V005 la fa obligatòria — cadascuna desplegable per separat, i entre elles es desplega el codi que les necessita.

La regla que resumeix les dues taules: en producció, la pregunta no és "funciona aquest ALTER TABLE?", sinó "què passa mentre s'executa, i què passa si falla a mitges?". Si no saps respondre les dues, la migració no està a punt.

• Escriure ALTER TABLE a mà en producció. L'error arrel del qual surten gairebé tots els altres.
• Creure que ADD COLUMN amb DEFAULT sempre reescriu la taula. Des de PostgreSQL 11 no ho fa, llevat que el DEFAULT sigui volàtil.
• Creure que una operació "instantània" és inofensiva. Necessita l'ACCESS EXCLUSIVE, i si no l'aconsegueix encua tota la càrrega darrere. lock_timeout, sempre.
• RENAME de cop. Trenca el codi antic en l'instant del COMMIT. Expand/contract, o no ho facis.
• ALTER COLUMN TYPE sense USING quan la conversió no és automàtica. El HINT de PostgreSQL et diu exactament què escriure.
• Reduir un VARCHAR sense comprovar les dades. PostgreSQL avorta; MySQL en mode relaxat trunca en silenci.
• ADD CONSTRAINT sense NOT VALID en taules grans. Escaneig complet amb bloqueig exclusiu.
• Esperar que canviar el DEFAULT actualitzi les files existents. No ho fa: només afecta les insercions futures.
• Fer servir DROP COLUMN com a esborrat segur de dades sensibles. La dada continua en disc fins que la fila es reescrigui.
• Suposar que el DDL és transaccional a tot arreu. A PostgreSQL, SQL Server i SQLite sí; a MySQL i Oracle, no: una migració a mitges es queda a mitges.
• Backfill en una sola transacció gegant. Bloqueja files, infla el WAL i si falla cal començar de zero. Per lots.
• Backfill que trepitja la doble escriptura. Afegeix WHERE columna IS NULL per tocar només el que falta.
• Migracions sense script de reversió. Escriure'l és la manera més barata de descobrir que el canvi no és reversible.
• Consell: \d taula abans i després de cada ALTER TABLE. Comprovar el que has fet costa dos segons.
• Consell: embolcalla les migracions en BEGIN … COMMIT si el teu motor ho permet. A PostgreSQL, quinze canvis passen a ser atòmics.
• Consell: mesura el temps en una còpia amb volum real abans de tocar producció. És la diferència entre una finestra de manteniment de cinc minuts i una de cinc hores.

Treballa sobre la base acabada de recarregar, dins de BEGIN … ROLLBACK.

BotigaVerda vol registrar el canal pel qual entra cada comanda (web o telefon), una dada que fins ara es deduïa indirectament de si empleat_id era NULL.

1. Afegeix a comandes una columna canal VARCHAR(10), obligatòria, amb valor per omissió 'web' i protegida amb un CHECK amb nom que només admeti 'web' i 'telefon'.
2. Omple cap enrere: les comandes amb comercial assignat són 'telefon'; la resta, 'web'.
3. Comprova el resultat agrupant per canal.
4. Respon: per què el pas 1 no requereix reescriure la taula? I què hauria passat si haguessis posat el CHECK abans d'omplir les dades?

Un company et passa aquest fitxer de migració perquè el revisis abans d'aplicar-lo a producció, on productes té 4 milions de files i linies_comanda 90 milions:

1. Identifica tots els problemes, indicant per a cadascun si és de bloqueig, de compatibilitat, de reversibilitat o de procés.
2. Estima quines de les sis operacions són instantànies i quines no.
3. Reescriu la migració com hauria d'estar, partint-la en els fitxers que calgui.

Aplica el patró expand/contract complet per afegir a clients una columna total_gastat NUMERIC(10,2) que acumuli el que cada client ha comprat (producte + ports).

1. Escriu les cinc fases, indicant a cadascuna què és canvi d'esquema, què és canvi de codi i què és canvi de dades.
2. Executa les fases 1, 3 i 5 sobre BotigaVerda (la 2 i la 4 són d'aplicació).
3. Verifica que la suma de total_gastat de tots els clients coincideix amb el total de comandes del curs.
4. Discuteix: ha de ser la columna NOT NULL? Quin valor tenen els tres clients sense comandes, i què implica això?

Solució 1

Deu i deu, exactament el repartiment que 01-06 descrivia: la meitat del canal és web. I les tres formes de COUNT de 04-04 confirmen la coherència: al canal telefon les 10 comandes tenen comercial, a web cap. Els ports sumen 72,15 € + 46,10 € = 118,25 €, la xifra canònica del mòdul 4 — i de passada revelen una cosa que no s'havia mirat mai: el canal telefònic paga bastants més ports, perquè concentra les comandes a Portugal i França.

4. Les dues preguntes.

Per què no reescriu la taula: el DEFAULT 'web' és una constant, i des de PostgreSQL 11 això es desa al catàleg i es retorna al vol per a les files antigues. Si el valor per omissió hagués estat alguna cosa volàtil, sí que hauria reescrit les 20 files (irrellevant aquí, decisiu amb 20 milions).

Què hauria passat amb el CHECK abans de les dades: en aquest cas concret, res dolent, perquè el DEFAULT 'web' deixa totes les files amb un valor vàlid. Però si haguéssim afegit la columna nul·lable i sense DEFAULT i després el CHECK, tampoc no hauria fallat: les 20 files tindrien NULL, i un CHECK que s'avalua a UNKNOWN s'accepta (05-01, apartat 3.5). El CHECK hauria passat sense protestar i amb la columna buida. És la trampa clàssica: l'ordre importa, però el CHECK no sempre t'avisa que has fet les coses a l'inrevés. El NOT NULL sí que ho hauria fet.

En una taula gran l'ordre correcte i segur seria: afegir la columna nul·lable → backfill per lots → ADD CONSTRAINT ... NOT VALID → VALIDATE CONSTRAINT → SET NOT NULL.

Solució 2

1 i 2. Els problemes, operació per operació:

I dos problemes de procés que afecten el fitxer sencer:

• Sis canvis heterogenis en una migració. Viola la primera regla d'or: si falla el quart, quedes a mitges (a PostgreSQL el ROLLBACK et salva; a MySQL, no).
• Sense lock_timeout. Qualsevol d'aquestes operacions pot encuar tota la càrrega darrere seu.

Estimació de temps amb aquells volums: les operacions 2, 3 i 4 es compten en minuts o hores cadascuna; la 5, en diversos minuts. La migració completa deixaria el catàleg inaccessible durant tot aquell temps.

3. La versió correcta, partida en fitxers:

I les tres operacions restants:

La lliçó de l'exercici: la major part d'una revisió de migracions consisteix a dir que no. De sis operacions, una està ben plantejada i cinc no s'haurien d'aplicar tal com estan.

Solució 3

1. Les cinc fases:

2. Execució de les fases 1, 3 i 5:

La temptació és fer-ho d'una sentència, unint clients, comandes i linies_comanda:

despeses_enviament viu a comandes, i després del JOIN cada comanda apareix tantes vegades com línies tingui: els ports es multiplicarien i la suma total donaria 278,70 € en lloc de 118,25 €. És exactament l'error que el mòdul 3 va advertir tres vegades i el 4 va liquidar.

La forma correcta és agregar en dues etapes, reutilitzant la taula totals_comanda de l'apartat 10:

Sofia Moreira Costa encapçala el rànquing amb 131,68 € en dues comandes, per davant de la Lucía, que n'ha fet tres. I els tres últims, amb NULL, són els clients sense comandes de 01-06.

3. Verificació:

846,20 €: la xifra canònica del curs (727,95 € de producte + 118,25 € de ports). Dotze clients amb compres i tres sense cap, exactament els buits deliberats de 01-06. Les tres formes de COUNT de 04-04 tornen a fer tota la feina de verificació.

4. La discussió. Ha de ser NOT NULL?

No hi ha resposta universal, i aquesta és la resposta correcta. Depèn de si "no ha comprat" i "ha comprat 0 €" són el mateix fet de negoci. A BotigaVerda no ho són: la Núria, l'Hugo i la Inés no han demanat mai res, i això és informació. Si es vol NOT NULL per comoditat aritmètica, cal documentar que el 0 significa dues coses i afegir una columna comandes_realitzades INTEGER NOT NULL DEFAULT 0 que sí que les distingeixi.

És exactament la discussió de 04-03, secció 11 —dissenyar amb NULL, amb sentinelles o amb NOT NULL— i la prova que una decisió d'esquema no és mai només tècnica.

I el problema obert, el mateix que amb comandes.total: aquesta columna és un agregat precalculat i cal mantenir-la sincronitzada. Cada comanda nova, cada línia modificada i cada devolució la deixen obsoleta. La solució —un trigger, o una vista materialitzada que es refresqui— és del mòdul 10. Mentre no existeixi, la columna és una bomba de rellotgeria, i per això la fase 2 del patró (la doble escriptura) no és opcional: és l'única que evita que la dada es podreixi.

ALTER TABLE tanca el mòdul 5 i amb ell, la teva capacitat d'operar sobre una base de dades completa:

• Les operacions d'ALTER TABLE: ADD COLUMN (instantània, fins i tot amb DEFAULT constant des de PostgreSQL 11, llevat que sigui volàtil), DROP COLUMN (instantània, irreversible i no un esborrat segur), RENAME (instantània i la més perillosa, perquè trenca el codi antic a l'acte), ALTER COLUMN TYPE amb USING per a les conversions no trivials, SET/DROP NOT NULL, SET/DROP DEFAULT —que no toca les files existents—, i ADD/DROP CONSTRAINT, on es cobra la insistència de 05-01 a anomenar-les.
• NOT VALID + VALIDATE CONSTRAINT: protecció immediata per a les files noves i comprovació de l'històric sense bloquejar lectures ni escriptures. La tècnica estàndard en taules grans.
• Què bloqueja i què no, amb la taula de nivells; i el detall que de debò tomba producció: una operació instantània que no aconsegueix l'ACCESS EXCLUSIVE encua tota la càrrega darrere seu. SET LOCAL lock_timeout és la protecció.
• DDL transaccional: a PostgreSQL, SQL Server i SQLite un ALTER TABLE es pot desfer amb ROLLBACK i una migració de quinze passos és atòmica; a MySQL i Oracle no, i una migració que falla a mitges es queda a mitges.
• Expand/contract: afegir el nou → escriure als dos → omplir cap enrere → canviar la lectura → eliminar el vell. Cinc fases en què mai no existeix un estat que trenqui l'aplicació. Demostrat amb comandes.total, el backfill idempotent del qual (WHERE total IS NULL) va quadrar en els 846,20 € canònics del curs.
• Migracions versionades: un fitxer numerat per canvi, al repositori, revisat com a codi, aplicat per una eina (Flyway, Liquibase, Alembic, Rails, Django, Laravel, Sqitch). I les cinc regles d'or: una migració = un canvi, sempre amb reversió, provada amb volum realista, amb còpia de seguretat verificada, i mai a mà en producció.

I amb això es tanca el mòdul 5. Repassa el que has guanyat en sis lliçons. Saps crear taules amb CREATE TABLE i declarar les sis restriccions que portaves cinc mòduls llegint, entenent per què CHECK accepta els nuls, per què UNIQUE n'admet diversos i per què GENERATED BY DEFAULT és el que obliga a aquell bloc de setval. Saps inserir amb INSERT, llistant sempre les columnes, en lots, i recuperant amb RETURNING l'id que necessites per penjar-hi les línies d'una comanda. Saps modificar amb UPDATE, amb un protocol de cinc passos i una transacció oberta, entenent que totes les assignacions s'avaluen sobre la fila antiga i que preu * 1.05 no és idempotent. Saps esborrar amb DELETE, distingir-lo de TRUNCATE, predir què s'endú per davant cada ON DELETE, i —el més important— decidir si cal esborrar, perquè actiu = FALSE existeix just per no fer-ho. Saps fusionar amb ON CONFLICT i amb MERGE, i per què mirar-i-després-decidir no és mai segur. I saps canviar l'esquema sense tombar el servei.

Ha canviat alguna cosa més que el repertori d'instruccions: ha canviat el nivell de responsabilitat. Als mòduls 2 a 4, un error teu retornava un número equivocat. Des d'aquest mòdul, un error teu modifica dades reals. Per això aquí has après tants hàbits com sintaxi: escriure el SELECT abans que l'UPDATE, comptar les files, obrir la transacció, comprovar el RETURNING, fer còpia abans, posar lock_timeout, versionar la migració. Cap d'aquells hàbits no apareix a la referència del llenguatge, i tots separen qui porta anys tocant bases de dades de qui en porta un mes.

Amb BotigaVerda ja ho pots fer tot: consultar-la, creuar-la, agregar-la, poblar-la, corregir-la i fer-la evolucionar. El que encara no pots és transformar i presentar el que en treus. Continues retornant nom i cognoms en dues columnes quan en vols una; continues escrivint ROUND(...) a mà sense conèixer-ne les germanes; continues sense poder extreure l'any d'una data, calcular l'antiguitat d'un client, posar un text en majúscules, convertir un tipus en un altre de manera explícita, substituir un NULL per un valor llegible, ni classificar files en categories segons una condició. Al mòdul 6, Funcions, arriben les eines que falten: funcions de cadena per compondre i netejar text, funcions numèriques per arrodonir i calcular amb criteri, funcions de data i hora per respondre per fi a "quants dies va trigar aquella comanda?", CAST i COALESCE per convertir tipus i domar els nuls que portes dos mòduls esquivant, i CASE per ficar lògica condicional dins d'una consulta. A partir d'aquí, les teves consultes deixaran de retornar dades i començaran a retornar respostes.