Escena Viva funciona sobre MongoDB i funciona bé. Aquesta lliçó no ve a desmuntar-ho: ve a mostrar l'altre món, el relacional, modelant exactament el mateix domini a PostgreSQL perquè vegis amb els teus propis ulls què canvia. Un desenvolupador de Node que només coneix un dels dos models té la meitat de les eines. I hi ha un motiu addicional molt concret: al món relacional apareixen dues peces que resolen d'arrel problemes que arrosseguem. Una és la restricció CHECK, que converteix venudes <= aforament en una llei del motor i no en una bona intenció nostra. L'altra són les transaccions, que arriben a la lliçó següent. Al final tindràs una segona implementació de src/repositoris/esdeveniments.js sobre Sequelize, intercanviable amb la de Mongoose sense tocar controladors ni domini.

1. El món relacional en deu minuts, i per què aquí les sessions sí que són una taula
2. L'esquema SQL d'Escena Viva
3. Instal·lar Sequelize, connectar i per què sync() està prohibit
4. Definir models i tipus de dades
5. Validacions de model davant de restriccions de base de dades
6. Associacions i consultes amb Sequelize
7. SQL parametritzat i la injecció
8. El repositori alternatiu sobre Sequelize
9. Mongoose davant de Sequelize: el criteri

Una base de dades relacional desa taules: conjunts de files amb les mateixes columnes, cadascuna d'un tipus declarat. Sobre aquesta estructura tan simple es construeix tot:

• Clau primària (PK). La columna que identifica unívocament cada fila; normalment un id autoincremental o un UUID.
• Clau forana (FK). Una columna que apunta a la PK d'una altra taula. El motor garanteix que el destí existeix: no pots inserir una comanda amb un usuari_id inexistent, ni esborrar un usuari que tingui comandes llevat que defineixis què fer. És la integritat referencial, i MongoDB no la té.
• NOT NULL, UNIQUE, DEFAULT. La columna ha de tenir valor, no es repeteix, o pren un valor per omissió.
• CHECK. Una condició arbitrària que tota fila ha de complir. És la més infravalorada i la que més ens interessa.

La diferència cultural profunda: aquí l'esquema és obligatori i el fa complir el motor. No pots inserir una fila amb un camp extra ni amb un tipus equivocat. Això incomoda al principi i salva projectes al cap de tres anys.

Normalitzar és organitzar les dades perquè cada fet es desi una sola vegada. Les formes normals són un cos teòric ampli, però a la pràctica es redueixen a tres regles: res de valors múltiples en una cel·la (si hi ha diverses sessions, es crea una taula); cada taula descriu una sola cosa; i res derivat d'alguna cosa que no sigui la clau. A MongoDB incrustem les sessions dins de l'esdeveniment perquè el model documental ho permet i el patró d'accés ho afavoria. A SQL, les sessions són una taula pròpia, i no és un caprici: és l'única forma natural de tenir una fila per sessió amb la seva pròpia clau primària, les seves pròpies restriccions —CHECK (venudes <= aforament) s'aplica per fila, és a dir, per sessió— i les seves pròpies claus foranes des d'entrades i comandes. Perdem la lectura d'un sol cop (ara un esdeveniment amb les seves sessions són dues taules i un JOIN) i guanyem integritat garantida pel motor. És exactament el compromís que descrivia la taula de la lliçó 07-01, ara amb noms propis.

Atura't a CONSTRAINT aforament_no_superat CHECK (venudes <= aforament). Aquesta línia és la resposta relacional al problema del curs. A MongoDB tenim un validador que Mongoose executa de vegades —recorda: no en updateOne sense runValidators, i sense accés a altres camps en actualitzacions parcials—. Aquí és el motor qui la comprova a cada INSERT i cada UPDATE, sense excepció, vingui de la teva aplicació, d'un script, d'algú amb psql o d'una migració mal escrita. És integritat que MongoDB, senzillament, no et dóna. I observa ON DELETE RESTRICT davant d'ON DELETE CASCADE: el primer impedeix esborrar un usuari amb comandes; el segon esborra les entrades en esborrar la seva comanda. Res d'entrades òrfenes: el motor no ho permet.

Sequelize pot crear les taules des dels teus models amb sequelize.sync(), sync({ alter: true }) o sync({ force: true }). És còmode a la primera hora d'un projecte i en producció està prohibit, per quatre raons que convé entendre i no només obeir. No hi ha historial: ningú no sap què va canviar, quan ni per què, i no es pot revisar en una pull request ni revertir. alter: true és impredictible: per canviar el tipus d'una columna la pot esborrar i recrear, perdent les dades, i no detecta reanomenaments. No preserva dades: afegir una columna NOT NULL a una taula amb un milió de files exigeix decidir quin valor tenen aquestes files, i sync no ho pregunta. I force: true a l'entorn equivocat és la forma més ràpida coneguda d'esborrar una base de dades de producció. L'alternativa són les migracions, primera meitat de la lliçó següent.

Esdeveniment, Comanda, Entrada i Usuari es defineixen igual, amb ENUM per a estat, canal i rol.

Sobre DECIMAL davant d'enters en cèntims: DECIMAL és exacte i correcte per a diners, però a Node arriba com a cadena —un number no pot representar tots els decimals de 128 bits— i obliga a fer servir aritmètica decimal a cada operació. La nostra convenció evita el problema d'arrel: els enters de JavaScript són exactes fins a 2⁵³, més que suficient per a qualsevol recaptació. FLOAT i DOUBLE estan descartats sense discussió: 0.1 + 0.2 !== 0.3. I JSONB mereix una nota: PostgreSQL desa JSON binari, indexable i consultable amb operadors propis, així que pots tenir camps documentals dins d'una base relacional; la frontera entre els dos mons és menys nítida del que suggereixen els debats.

És la mateixa pregunta que a la 07-02 amb zod i Mongoose, amb la mateixa resposta: calen totes dues, perquè protegeixen de coses diferents.

L'estratègia professional: validació al model per donar bons missatges i estalviar viatges; restricció a la base com a xarxa de seguretat definitiva. Si només en poguessis triar una, tria la restricció: és l'única que no es pot burlar. Un CHECK sobreviu al teu codi, al teu ORM i al teu equip.

getSessions() és una altra consulta: si la crides dins d'un bucle sobre esdeveniments, acabes de reinventar l'N+1 de la lliçó anterior. La solució a Sequelize és include.

Els operadors viuen a Op i es corresponen gairebé un a un amb els de MongoDB: Op.eq/Op.ne i les comparacions (gt, gte, lt, lte) són $eq, $ne, $gt…; Op.between, Op.in i Op.notIn són $gte+$lte, $in i $nin; Op.like/Op.iLike (que ignora majúscules) fan el paper de $regex; i Op.and, Op.or, Op.not són els lògics.

I ara la diferència clau davant de populate:

Això és el que populate no pot fer. Amb include: una consulta, el motor uneix, filtra i ordena amb els seus índexs i el seu optimitzador, i pots filtrar l'esdeveniment per una condició sobre les seves sessions; amb populate eren dues consultes cosides a Node i filtrar el pare era impossible. A canvi, un include mal plantejat sobre tres relacions pot generar un producte cartesià enorme; per a això existeix separate: true.

Al mòdul 6 vam prometre tornar sobre la injecció. S'entén en dos blocs.

Si el client envia sala=x' OR '1'='1, la sentència executada és SELECT * FROM esdeveniments WHERE sala = 'x' OR '1'='1' i retorna la taula sencera. Amb sala=x'; DROP TABLE entrades; -- el motor rep dues sentències i la segona destrueix dades. La fallada conceptual és que la dada de l'usuari s'ha convertit en codi SQL: el motor rep una cadena i no pot distingir quina part vas escriure tu i quina part l'atacant.

Per què és immune, i no és "perquè escapa les cometes": amb paràmetres, el controlador envia la plantilla de la sentència per un costat i els valors per un altre. PostgreSQL analitza i planifica la sentència abans de conèixer els valors; quan arriben, l'arbre sintàctic ja està fixat i un valor només pot ocupar el forat d'un literal. x' OR '1'='1 es busca com el text literal d'una sala anomenada així, no com a lògica. És una separació estructural, no un filtratge de caràcters, i per això funciona fins i tot amb entrades que ningú no va preveure. Tot l'ORM parametritza per defecte: cada where, cada create, cada update genera SQL amb marcadors, així que mentre facis servir la seva API estàs protegit sense pensar-hi. El risc apareix en tres llocs: sequelize.query sense replacements, sequelize.literal amb dades d'usuari a dins, i qualsevol SQL construït amb plantilles de cadena. Un matís important: els paràmetres substitueixen valors, no identificadors, així que un ORDER BY dinàmic exigeix llista blanca.

L'ORM cobreix gairebé tot, però hi ha consultes —CTE recursives, funcions de finestra, INSERT ... ON CONFLICT afinats— que s'escriuen millor a mà. Baixar a SQL cru amb sequelize.query i substitucions no és un fracàs: és fer servir l'eina adequada. Això sí, encapsula-ho dins del repositori: que un controlador no vegi mai una cadena SQL.

Aquí l'arquitectura de la lliçó 07-01 cobra el premi: mateixa signatura pública, mateixa sortida —instàncies del domini—, un altre motor a sota.

Aquest interruptor és tota la prova que necessitàvem: els quatre controladors d'esdeveniments, les rutes, el middleware de validació, la jerarquia d'errors i el domini sencer funcionen igual amb MongoDB o amb PostgreSQL. L'abstracció que semblava burocràcia a la lliçó 07-01 acaba d'estalviar una reescriptura completa.

El criteri, sense dogmes. Tria documental quan les teves dades són agregats autocontinguts, l'esquema evoluciona ràpid, el volum de lectura és alt i la forma varia entre elements. Tria relacional quan hi ha diners, invariants dures, moltes relacions creuades i informes complexos, i quan la correcció importa més que la flexibilitat. Escena Viva, honestament, és un cas de llibre per al model relacional: aforaments, pagaments, entrades nominals, comptabilitat. Ho hem fet a MongoDB perquè funciona i perquè cal saber-ho fer, i a la lliçó següent veurem les dues solucions a la sobrevenda, una per motor. Altres opcions que convé conèixer: Prisma, l'ORM modern més popular a Node, amb el seu propi llenguatge d'esquema, tipatge excel·lent i migracions molt curades, encara que s'allunya del SQL i les consultes complexes se li entravessen; i Knex, que no és un ORM sinó un constructor de consultes amb API encadenable, sense models ni màgia. Molts equips combinen un ORM per al CRUD i Knex o SQL cru per al que és difícil.

• Cridar sync({ alter: true }) a l'arrencada. Un dia alterarà alguna cosa que no volies, en producció, sense registre. Migracions.
• No indexar les claus foranes. PostgreSQL crea l'índex de la PK, però no el de les columnes FK: un JOIN sense ell recorre la taula sencera.
• Fer servir FLOAT per a diners, o concatenar entrada d'usuari a sequelize.query: enters en cèntims i replacements, sempre.
• Confiar només en les validacions del model. Se salten amb bulkCreate o SQL cru. Les restriccions del motor no.
• Carregar relacions dins d'un bucle amb getSessions(): és l'N+1 amb un altre nom. Fes servir include.
• Consell: activa logging: console.log en desenvolupament i llegeix el SQL que genera Sequelize —és la millor manera d'aprendre SQL i de detectar consultes absurdes—, i aprèn EXPLAIN ANALYZE de PostgreSQL: és l'explain() de la lliçó anterior amb més informació.

Escriu src/models-sql/entrada.js amb Model.init: codi (únic, amb validate.is per al format EV-<any>-<6 dígits>), comandaId, sessioIdRef, estat (ENUM, per defecte valida) i usadaEl (DATE, nul). Afegeix les associacions i digues quin mètode generat et donaria les entrades d'una comanda.

Aquest endpoint és vulnerable. Explica l'atac concret i reescriu-lo de forma segura, sabent que ordre pot valer titol o sala.

Exercici 1.

Amb Comanda.hasMany(Entrada, { as: 'entrades', foreignKey: 'comanda_id' }), el mètode és comanda.getEntrades(). Per a diverses comandes alhora, include en lloc del mètode, per no caure en N+1.

Exercici 2. Hi ha dues vulnerabilitats. A terme, un valor com x%' UNION SELECT id, correu, nom, rol, null, null FROM usuaris -- filtra la taula d'usuaris sencera. A ordre, titol; DROP TABLE entrades; -- injecta una segona sentència. I ordre no es pot parametritzar perquè és un identificador, no un valor: cal validar-lo contra una llista blanca.

El % va dins del valor del paràmetre, no de la plantilla: així continua sent dada. I columna s'interpola només després d'haver estat validada contra un conjunt tancat.

Has vist el mateix domini dues vegades, i aquesta és la lliçó. Saps llegir i escriure un esquema relacional amb claus primàries i foranes, NOT NULL, UNIQUE i aquell CHECK (venudes <= aforament) que converteix una invariant de negoci en una llei del motor. Saps connectar Sequelize a PostgreSQL des de la configuració, per què sync() no pot trepitjar producció, com definir models amb tipus adequats —enters en cèntims, mai coma flotant—, per què conviuen les validacions del model i les restriccions de la base, com declarar associacions i quins mètodes generen, i com consultar amb where, include —un JOIN real d'una sola consulta, a diferència de populate—, agregacions i SQL cru quan cal. Has tancat la promesa del mòdul 6: la injecció s'evita separant la sentència de les dades, no escapant cometes. I sobretot, el patró repositori ha fet el que prometia: src/repositoris/esdeveniments-sql.js substitueix src/repositoris/esdeveniments.js amb un interruptor de configuració, i ni un sol controlador ni una sola classe del domini se n'ha assabentat.

Queda l'última lliçó del mòdul, i és la que esperaves des del mòdul 4. Migracions per versionar l'esquema com es versiona el codi, llavors per carregar per fi els 3 esdeveniments i les 7 sessions de dades/esdeveniments.json i jubilar el fitxer per sempre, i transaccions: què és ACID a la pràctica, com dos compradors concurrents exhaureixen l'última entrada, per què ni $inc ni una comprovació prèvia no basten, nivells d'aïllament, blocatge pessimista davant d'optimista, i la implementació definitiva de comprarEntrades que reserva aforament, crea la comanda i emet les entrades o no fa absolutament res.