Ja sabem què és NoSQL, per què existeix i com s'opera cadascuna de les seves quatre famílies. I tanmateix, amb tot això, encara no sabem fer el més important: dissenyar bé.

Aquesta és la lliçó on més projectes es torcen. La sintaxi de MongoDB s'aprèn en una tarda; el modelatge documental és on es decideix si el sistema anirà bé d'aquí a dos anys o si caldrà reescriure'l. I el parany és que un mal disseny funciona perfectament el primer dia: amb 200 documents tot és ràpid i no falla res. El dany apareix quan la col·lecció creix, quan un document s'acosta al seu límit de mida o quan algú descobreix que el nom d'una sucursal està duplicat en 40.000 documents i acaba de canviar.

Invertirem l'ordre mental que vam aprendre al mòdul 2, definirem amb precisió què és un agregat, resoldrem la decisió més important del modelatge documental —incrustar o referenciar— amb criteris explícits en lloc d'intuïció, aprendrem els cinc patrons de disseny que resolen gairebé tots els casos reals i els quatre antipatrons que els espatllen, i recuperarem part de les garanties perdudes amb la validació d'esquema.

El lliurable al final és concret: el disseny definitiu de les tres col·leccions de BiblioRed —ressenyes, cataleg i activitat— amb documents d'exemple i la justificació de cada decisió.

1. El canvi de mentalitat: del domini a les consultes
2. L'agregat: unitat de lectura, escriptura i atomicitat
3. La decisió central: incrustar o referenciar
4. Un a pocs, un a molts, un a moltíssims
5. Duplicació controlada i com mantenir-la coherent
6. Patró: referència estesa
7. Patró: subconjunt
8. Patró: agrupació (bucket)
9. Patró: valor atípic (outlier)
10. Patró: camp calculat
11. Antipatrons que cal reconèixer
12. Validació d'esquema amb $jsonSchema
13. Versionatge de documents i evolució de l'esquema
14. Els índexs, breument
15. Lliurable: el disseny final de les col·leccions de BiblioRed
16. Errors habituals i consells
17. Exercicis
18. Conclusió

Al mòdul 2 vam seguir, sense anomenar-lo, un mètode molt concret:

1. Identificar les entitats del domini: sucursals, socis, llibres, exemplars, préstecs.
2. Donar a cadascuna la seva taula, amb les seves claus i les seves relacions.
3. Normalitzar per eliminar la redundància (ho formalitzarem al mòdul 5).
4. I després escriure les consultes, amb la confiança que el model aguantarà qualsevol pregunta.

Aquest últim punt és la gran virtut del model relacional: un esquema ben normalitzat respon a preguntes que ningú no havia previst. El disseny és independent de l'ús.

A NoSQL l'ordre s'inverteix:

1. Enumerar les consultes que l'aplicació necessita servir, amb la seva freqüència i la seva exigència de latència.
2. Dissenyar els documents perquè cada consulta freqüent es resolgui amb un sol accés.
3. Acceptar la duplicació que calgui per aconseguir-ho.
4. I després comprovar que les entitats del domini continuen sent reconeixibles.

Això té una conseqüència incòmoda que convé acceptar com abans millor: el mateix domini admet dissenys documentals completament diferents segons com es consulti. No existeix "el model correcte d'una biblioteca" a MongoDB; existeix el model correcte per al portal de BiblioRed amb aquestes consultes. Si demà canvia radicalment l'ús, el model pot quedar obsolet encara que el domini no hagi canviat.

Per això el primer pas del modelatge documental no és dibuixar entitats, és escriure la llista de consultes. La de BiblioRed, prioritzada:

Tot el que ve a continuació és la resposta a aquesta taula.

Vam introduir el concepte a la lliçó 03-01. Ara el precisem, perquè és l'eina principal de treball.

Un agregat és un conjunt de dades que compleix les tres condicions alhora:

1. Es llegeix junt: l'aplicació gairebé mai no necessita una part sense les altres.
2. S'escriu junt: els canvis afecten el conjunt de manera coherent.
3. Té una arrel: una entitat principal que dóna identitat al conjunt i per la qual s'hi accedeix.

I d'aquí surt la propietat que governa tot el disseny:

L'agregat és la frontera de l'atomicitat. A MongoDB, l'escriptura d'un document és atòmica: o s'aplica sencera o no s'aplica. Tot el que quedi dins del document s'actualitza d'una peça, sense transacció. Tot el que quedi fora necessita una transacció explícita o quedarà exposat a incoherències temporals.

Aquesta frase és el criteri de disseny més útil que t'endús de la lliçó. Quan dubtis entre posar una cosa dins o fora, pregunta't: necessito que això canviï de manera atòmica juntament amb la resta? Si la resposta és sí, dins.

Exemple a BiblioRed. Una ressenya amb el seu text, la seva puntuació, les seves etiquetes i el seu recompte de vots és un agregat: quan un lector edita la seva ressenya, canvia el text i les etiquetes alhora, i ningú no ha de veure el text nou amb les etiquetes velles. En canvi, la ressenya i la fitxa del material no formen un agregat: la fitxa s'edita des del panell del bibliotecari, la ressenya des del portal públic, amb ritmes i responsables diferents.

Tota la pràctica del modelatge documental es concentra en aquesta pregunta: quan dues entitats estan relacionades, el fill va dins del document del pare o a la seva pròpia col·lecció amb una referència?

No ho decideixis per intuïció. Recorre aquests sis criteris en ordre:

El criteri 5 mereix un avís especial, perquè és el que més sistemes ha trencat: tot el que creix amb el temps i no té topall acaba sent un problema si està incrustat. Les ressenyes d'un llibre popular, els esdeveniments d'activitat, els missatges d'un xat, l'historial de préstecs. Encara que avui siguin tres, d'aquí a cinc anys en seran milers. I hi ha un cost que no es veu venir: MongoDB, en actualitzar un document que ha crescut, pot haver de reescriure'l sencer al disc. Un document de 8 MB al qual s'afegeix un element de 200 bytes costa reescriure 8 MB.

Si el fill no té sentit sense el pare i desapareix amb ell, gairebé sempre va incrustat. Una adreça sense el seu soci no significa res: dins. Una ressenya, en canvi, té identitat pròpia —s'enllaça, es vota, es denuncia, apareix al perfil del seu autor—: fora.

La manera més ràpida d'aplicar els sis criteris és classificar la relació per la seva cardinalitat. És la regla pràctica més citada del modelatge documental i funciona sorprenentment bé.

La diferència entre les dues últimes files és subtil i crucial. A un a molts, el pare pot guardar la llista d'identificadors dels seus fills, perquè hi cap. A un a moltíssims, aquesta llista seria un array de 40.000 elements que creix cada dia: l'enllaç ha d'anar només al fill, que apunta cap amunt.

Aplicat a BiblioRed, cas per cas:

Material i etiquetes → incrustar. Un material té entre tres i vuit etiquetes, no creixen sense control, es mostren sempre amb la fitxa i no es consulten per separat (la cerca per etiqueta es resol amb un índex sobre l'array incrustat, no amb una altra col·lecció). Els sis criteris apunten a incrustar.

Material i ressenyes → referenciar, amb subconjunt. Les ressenyes creixen sense topall, es consulten per separat (perfil del soci, moderació), canvien sovint (vots útils, edicions, respostes) i són l'entitat principal de la consulta C2. Van a la seva pròpia col·lecció. Però la consulta C1 —la més freqüent del sistema— vol la fitxa amb les seves millors ressenyes en un sol accés, així que el document del material guarda a més una còpia de les cinc millors. Això és el patró de subconjunt de l'apartat 7.

Material i exemplars → ni una cosa ni l'altra. Els exemplars físics, amb el seu estat i la seva sucursal, es queden a PostgreSQL. Estan íntimament lligats als préstecs, que són transaccionals. El catàleg de MongoDB guarda només un comptador desnormalitzat de disponibilitat per poder pintar "3 disponibles a Centre" sense consultar l'altra base. Reconèixer que una dada no ha de migrar també és una decisió de modelatge.

Soci i activitat → un a moltíssims. Cada esdeveniment és un document (o millor, un element dins d'un document d'agrupació, apartat 8) que apunta al soci. El document del soci no guarda cap llista d'esdeveniments.

Al mòdul 2 la redundància era l'enemic. En el modelatge documental és una eina. Però és una eina amb tall, i cal agafar-la pel mànec.

La duplicació es justifica quan el cost de mantenir-la és menor que el cost de reconstruir la dada a cada lectura. I aquest càlcul depèn gairebé sempre d'una sola pregunta: amb quina freqüència canvia la dada duplicada, comparada amb la freqüència amb què es llegeix?

Hi ha tres categories de dada duplicada, i es tracten de manera diferent:

No canvien mai, així que duplicar-les és gratis.

L'ISBN d'un llibre i el seu any de publicació són fixos. Copia'ls sense remordiment.

Aquí la duplicació no és una optimització: és correcció semàntica.

Si la Marta canvia de cognom el 2027, cal reescriure les seves 34 ressenyes? Depèn de què representi el camp:

• Si és "el nom que es mostra ara", sí: cal propagar-ho.
• Si és "qui va signar això el març del 2026", no: és una dada històrica i reescriure-la seria falsificar-la.

És la mateixa distinció que en una factura: el preu del producte en el moment de la venda es copia a la línia de factura i no es toca mai més, encara que el catàleg canviï demà. Decidir explícitament en quina categoria cau cada camp duplicat —i escriure-ho a la documentació del projecte— evita discussions i errors més endavant.

Són les perilloses. El títol d'un material apareix a les seves ressenyes; si el bibliotecari el corregeix, hi ha ressenyes amb el títol vell.

Tres estratègies, amb el seu cost:

I aquí apareix amb tota la seva cruesa el preu de NoSQL que vam anunciar a 03-01: aquestes dues operacions no són atòmiques entre si. Si el procés cau entre la primera i la segona, el catàleg té el títol nou i 47 ressenyes el vell. A PostgreSQL aquest problema senzillament no existiria, perquè el títol seria en un sol lloc.

Les defenses disponibles: embolcallar totes dues escriptures en una transacció de MongoDB (possible des del 2018, amb cost de rendiment), o —més habitual— dissenyar el sistema perquè el desfasament temporal sigui tolerable i programar un procés periòdic de reconciliació que detecti i corregeixi les divergències.

Regla d'or: duplica només el que es mostra, mai el que es fa servir per decidir. Duplicar el títol d'un material per pintar-lo en una llista és raonable. Duplicar-ne el preu o l'estat de disponibilitat per prendre una decisió de negoci a partir de la còpia, no.

Problema. Referenciar és correcte, però obliga a una segona consulta per mostrar quatre dades del document referenciat.

Solució. Al costat de la referència, copiar els pocs camps que la vista necessita. Ni tots ni cap: els que es pinten.

Criteri de selecció de camps: copia el que sigui estable i es mostri. El títol i el tipus són estables; la portada canvia molt de tant en tant. No copiïs la sinopsi (llarga i editable) ni el nombre d'exemplars disponibles (canvia a cada préstec). Per a això hi ha la referència.

Quan aplicar-lo: és el patró més usat i més útil del modelatge documental. Qualsevol llista que mostri elements de dues col·leccions n'és candidata.

Problema. El document del material podria contenir totes les seves ressenyes, però un títol popular en té 800 i la fitxa només mostra les cinc millors. Incrustar 800 documents per pintar-ne cinc és carregar 160 vegades més dades de les necessàries a la consulta més freqüent del sistema.

Solució. Guardar al pare una còpia del subconjunt que la vista necessita, i el conjunt complet a la seva pròpia col·lecció.

Amb això, la consulta C1 —la fitxa completa, la més freqüent del portal— és un sol findOne. Qui premi "veure les 812 ressenyes" farà una segona consulta a ressenyes, però això només ho fa una fracció dels visitants.

Com es manté el subconjunt. Cada vegada que una ressenya puja de vots, es comprova si hauria d'entrar al destacat:

Aquest recàlcul no ha de ser immediat: pot executar-se cada pocs minuts en segon pla. Que una ressenya trigui deu minuts a aparèixer al destacat no molesta ningú, i a canvi s'evita executar el recàlcul a cada vot.

Quan aplicar-lo: sempre que la vista principal necessiti només els N primers d'una col·lecció gran.

Problema. El registre d'activitat genera 17 milions d'esdeveniments l'any. Un document per esdeveniment significa 17 milions de documents diminuts, cadascun amb la sobrecàrrega del seu _id, la seva entrada d'índex i les seves metadades internes. En molts casos, la sobrecàrrega pesa més que la dada.

Solució. Agrupar els esdeveniments d'una mateixa entitat i un mateix període en un sol document contenidor.

La inserció d'un esdeveniment es converteix en una única operació que crea el contenidor si no existeix i afegeix l'esdeveniment si ja existeix:

upsert: true és la clau: si el document del dia no existeix, es crea; si existeix, s'actualitza. $setOnInsert posa els camps fixos només en la creació, per no reescriure'ls cada vegada.

Les xifres del canvi, amb les estimacions de BiblioRed:

Com triar la mida del contenidor. Per soci i dia és el natural a BiblioRed. Però un usuari molt intensiu podria generar centenars d'esdeveniments diaris, així que cal posar-hi un topall: quan un contenidor arriba a, per exemple, 500 esdeveniments, se n'obre un altre (ACT-14-2026-08-02-2). Un contenidor sense topall es converteix en un array il·limitat, que és justament l'antipatró de l'apartat següent.

Quan aplicar-lo: sèries d'esdeveniments, telemetria, mesuraments, registres d'auditoria. És la resposta documental al problema que a 03-02 vam adjudicar a Cassandra, i la raó que BiblioRed pugui resoldre'l sense desplegar una altra base.

Problema. El 99,8 % dels materials de BiblioRed té menys de 50 ressenyes, i per a ells incrustar-les seria perfecte. Però tres o quatre supervendes en tenen milers. Si es dissenya per al cas extrem, es penalitzen els 39.996 materials normals; si es dissenya per al cas normal, els quatre extrems trenquen el sistema.

Solució. Dissenyar per al cas comú i marcar els excepcionals amb un indicador que activi un camí alternatiu.

Cost: l'aplicació té dos camins de lectura, i això és complexitat real que cal documentar i provar. Per això aquest patró s'aplica només quan la distribució és realment asimètrica i el cas extrem és una minoria diminuta. Si el 20 % dels materials desborda, no hi ha valor atípic: hi ha un mal disseny i toca referenciar per a tothom.

Problema. La fitxa d'un material mostra la seva puntuació mitjana. Calcular-la a cada visita significa recórrer les seves 812 ressenyes amb una agregació, per a una pàgina que es demana milers de vegades al dia.

Solució. Guardar el resultat ja calculat al document i actualitzar-lo quan canviïn les dades d'origen.

Fixa't en suma_puntuacions: guardar la suma a més de la mitjana permet actualitzar-la incrementalment, sense recórrer res.

Risc: el camp calculat pot desviar-se de la realitat si alguna escriptura falla o si s'esborra una ressenya sense descomptar-la. Defensa habitual: un procés nocturn que recalcula des de zero i corregeix. Un comptador que només puja mai no torna sol al seu lloc.

Quan aplicar-lo: quan la relació lectures/escriptures és molt alta. Aquí és de milers a un; el patró es paga sol.

L'antipatró número u, i el més fàcil de cometre.

Què passa, en ordre d'aparició: el document creix fins a acostar-se al límit de 16 MB; cada $push obliga a reescriure un document cada vegada més gran; les lectures transfereixen megabytes per fer servir dos camps; els índexs sobre l'array es disparen de mida; i un dia una escriptura falla amb BSONObjectTooLarge i no hi ha arranjament ràpid.

Senyal d'alarma: si no pots dir el nombre màxim d'elements que tindrà un array, no l'incrustis. Referencia o agrupa.

Encara que no hi hagi arrays il·limitats, un document pot engreixar-se per acumulació: la sinopsi completa, la portada en base64, el text extret del PDF, l'històric de canvis... tot dins de la fitxa del material.

Conseqüència: cada lectura de la fitxa —per mostrar el títol i la portada en miniatura— transfereix el document sencer des del disc a la memòria i d'allà a la xarxa. La memòria cau del servidor s'omple de dades que ningú no mira, i se'n desallotgen documents que sí que es fan servir.

Regla: les dades grans que es consulten molt de tant en tant van a la seva pròpia col·lecció, o directament fora de la base de dades —les imatges, a un magatzem d'objectes o a un sistema de fitxers, amb la URL al document—.

L'extrem contrari: 17 milions de documents de 80 bytes. La sobrecàrrega per document (identificador, entrades d'índex, metadades) supera la dada útil, els índexs no caben en memòria i les consultes per rang obliguen a llegir milions de documents dispersos.

Solució: el patró d'agrupació de l'apartat 8.

És l'antipatró més car perquè no dóna la cara: el sistema funciona, simplement funciona pitjor del que funcionaria PostgreSQL.

Aquest codi és un esquema relacional escrit a MongoDB, i hereta el pitjor dels dos mons: la lentitud d'unir sense les optimitzacions d'un planificador relacional madur, i la manca d'integritat referencial de la base documental. Si el teu disseny acaba aquí, la conclusió correcta no és "cal optimitzar la canalització": és "aquest domini volia PostgreSQL".

$lookup és legítim per a informes ocasionals i processos per lots. No ho és com a mecanisme habitual de la ruta de lectura principal.

L'esquema flexible és un avantatge mentre l'equip és disciplinat. MongoDB permet recuperar part de la xarxa de seguretat de manera voluntària i gradual, que és justament el que es necessita: regles fortes on importen, llibertat on convé.

Prova que funciona:

Tres errors capturats en l'escriptura, que és exactament on volíem. El de la data com a cadena és el més valuós: és l'error de la lliçó 03-01 que arruïna tota agregació posterior, i aquí no arriba ni a entrar.

Els dos paràmetres de comportament:

Estratègia recomanada per a una col·lecció que ja té dades: començar amb validationAction: "warn" per descobrir quants documents incomplirien sense trencar res, corregir-los, i només llavors passar a error. I fer servir moderate mentre quedin documents antics per migrar, per no bloquejar les actualitzacions del que encara no compleix.

Què no fa $jsonSchema, per no crear falses expectatives: no comprova que material_id apunti a un material existent. La integritat referencial continua sense existir. Valida forma, no referències.

En una base relacional, canviar la forma de les dades és un ALTER TABLE que afecta totes les files alhora, amb el seu bloqueig i la seva finestra. En una documental hi ha una alternativa molt més còmoda: no migrar res i conviure amb diverses versions.

La tècnica és senzilla i consisteix en un camp:

L'aplicació llegeix el camp i sap què esperar:

Tres estratègies de migració, en ordre d'agressivitat:

L'advertiment imprescindible: conviure amb diverses versions té un cost, i és el codi que les gestiona. Si l'equip acumula sis versions actives, la funció de normalització es converteix en un laberint de condicionals que ningú no gosa tocar. Conviu amb dues, potser tres, i tanca les migracions: quan el recompte d'una versió antiga arriba a zero, esborra la seva branca de codi.

Tot el que hem dit sobre modelatge suposa que les consultes es resolen eficientment, i això depèn dels índexs tant a MongoDB com a PostgreSQL.

La bona notícia és que la lògica és la mateixa que aprendràs a la lliçó 06-03: un índex és una estructura auxiliar —normalment un arbre B— que evita recórrer totes les dades; accelera les lectures, alenteix les escriptures, ocupa espai, i l'ordre dels camps en un índex compost determina quines consultes pot servir.

Les particularitats documentals, en quatre línies:

• Es pot indexar qualsevol camp, encara que estigui imbricat: db.ressenyes.createIndex({ "soci.soci_id": 1 }).
• Es pot indexar el contingut d'un array (índex multiclau): una entrada per element. És el que fa ràpida la cerca per etiqueta.
• L'índex TTL esborra documents automàticament passat un temps, i és el que BiblioRed farà servir per caducar l'activitat als dos anys.
• explain() és l'equivalent d'EXPLAIN en SQL i diu si la consulta ha fet servir un índex o ha recorregut la col·lecció sencera.

No hi aprofundim més: els índexs tenen la seva lliçó pròpia al mòdul 6.

Aquí hi ha el resultat d'aplicar tot l'anterior. Tres col·leccions a la base bibliored de MongoDB, cada decisió justificada.

Arrel de l'agregat: el material. Respon a: C1 (fitxa completa) i C4 (cerca).

I un document d'un altre tipus, a la mateixa col·lecció, perquè es vegi l'heterogeneïtat:

Índexs: { titol_normalitzat: 1 }, { etiquetes: 1 }, { tipus: 1, "valoracio.mitjana": -1 }, { "autors.autor_id": 1 }.

Arrel de l'agregat: la ressenya. Respon a: C2, C3 i C5.

Índexs: { "material.material_id": 1, vots_utils: -1 }, { "soci.soci_id": 1, data: -1 }, { estat: 1, data: -1 }, { etiquetes: 1 }.

Arrel de l'agregat: el conjunt d'esdeveniments d'un soci en un dia. Respon a: C6, C7 i C8.

Índexs: { soci_id: 1, dia: -1 }, { dia: 1 } amb expireAfterSeconds: 63072000, { "esdeveniments.material_id": 1 }.

Fixa't en l'estil de les fletxes: les contínues són còpies de dades que cal mantenir coherents; les discontínues són referències que l'aplicació resol quan cal. Cada fletxa contínua és una responsabilitat de coherència que algú ha d'assumir al codi, i per això convé que en siguin poques i estiguin documentades. Aquí n'hi ha exactament dues.

Error 1: començar dibuixant entitats. És el reflex que portem del model relacional i aquí condueix a col·leccions normalitzades cosides amb $lookup. Comença sempre per la llista de consultes.

Error 2: incrustar "perquè és el que es fa a MongoDB". Incrustar és correcte per a un a pocs. Per a un a molts i un a moltíssims és una bomba de rellotgeria que esclata en producció, no en desenvolupament.

Error 3: duplicar sense decidir la categoria de la dada. Cada camp duplicat ha d'estar classificat: immutable, històric congelat o viu amb propagació. Si no ho escrius, d'aquí a sis mesos ningú no sabrà si cal actualitzar-lo.

Error 4: confiar que l'esquema flexible es documenta sol. No es documenta. Escriu el $jsonSchema encara que el posis en warn: és documentació executable del contracte de la col·lecció.

Error 5: provar el disseny només amb dades de joguina. Un disseny amb 200 documents sempre sembla bo. Genera 500.000 documents sintètics amb la distribució real esperada —inclosos els valors atípics— i mesura abans de donar res per bo.

Error 6: oblidar que l'aplicació és ara la responsable. No hi ha cap FOREIGN KEY que impedeixi una ressenya sobre un material inexistent. Si l'esborrat d'un material ha d'arrossegar les seves ressenyes, aquest CASCADE l'escrius tu.

Consell 1: escriu la fitxa de decisió de cada col·lecció. Arrel de l'agregat, consultes que serveix, què s'incrusta i per què, què es duplica i de quina categoria és, índexs. Mitja pàgina per col·lecció que estalvia setmanes.

Consell 2: anomena els camps de manera consistent i curta on es repeteixen molt. Dins d'un array de milers d'elements, t en lloc de timestamp estalvia megabytes reals. Fora d'aquí, prioritza la llegibilitat.

Consell 3: posa el camp esquema_v des del primer document. Costa quatre bytes i el dia que el necessitis —i el necessitaràs— t'estalviarà una migració massiva a cegues.

Consell 4: revisa el disseny quan canviïn les consultes, no quan canviï el domini. És el corol·lari de l'apartat 1 i l'avís més important de la lliçó: al món documental, un canvi en com es fan servir les dades pot obligar a redissenyar encara que les dades siguin les mateixes.

BiblioRed vol afegir clubs de lectura: grups amb nom, sucursal de reunió, entre 8 i 25 socis membres, un llibre assignat cada mes i un fil de comentaris per cada llibre llegit (uns 30–60 comentaris per llibre, i el club pot portar anys en marxa). Decideix per a cada relació si incrustes o referencies, justificant-ho amb els sis criteris de l'apartat 3, i escriu el document d'exemple de la col·lecció clubs.

Aquest document té quatre problemes de disseny. Identifica'ls, digues quin antipatró o mal criteri representa cadascun i proposa el disseny corregit.

Escriu la validació $jsonSchema de la col·lecció activitat dissenyada a l'apartat 15.3, exigint: soci_id enter positiu obligatori; dia de tipus data obligatori; num_esdeveniments enter entre 0 i 500; esdeveniments array obligatori de màxim 500 elements, on cada element tingui obligatòriament t (data) i tipus (un de cerca, fitxa, filtre, reserva, descarrega). Després explica per què convindria desplegar-la amb validationAction: "warn" abans que amb "error".

Solució 1

Club i els seus membres → incrustar. Cardinalitat de 8 a 25, amb topall natural imposat pel mateix reglament del club (criteri 1: pocs). Es mostren sempre amb la fitxa del club i no es consulten per separat (criteri 2). Canvien poc: algú entra o surt unes quantes vegades l'any (criteri 3). Ocupen uns pocs kilobytes (criteri 4). El creixement està acotat pel màxim de places (criteri 5). I les altes i baixes han de ser coherents amb el recompte de places lliures, cosa que afavoreix l'atomicitat del mateix document (criteri 6). Sis de sis a favor d'incrustar, amb referència estesa al nom del soci.

Club i el seu calendari de lectures → incrustar, però vigilant. Dotze llibres l'any. Al cap de cinc anys són seixanta elements: continua sent un a pocs i hi cap de sobres. Es mostra sencer a la fitxa del club ("què hem llegit"). S'incrusta, i es deixa anotat que si un club superés els ~200 elements convindria separar l'històric antic.

Club i comentaris de cada llibre → referenciar. Aquí el criteri 5 mana: 40 comentaris per llibre × 12 llibres l'any × diversos anys és creixement sense topall (criteris 1 i 5). A més tenen vida pròpia —es moderen, es responen, s'enllacen— (criteri 2), canvien amb freqüència (criteri 3) i no necessiten canviar atòmicament amb el club (criteri 6). Col·lecció pròpia comentaris_club, amb el subconjunt dels tres últims incrustat al club per poder mostrar "última activitat" sense una segona consulta.

Solució 2

Un detall deliberat: _id és 14, el mateix identificador que el soci_id de PostgreSQL. Quan una entitat existeix a les dues bases, compartir l'identificador és la decisió que menys disgustos dóna.

Solució 3

Fixa't en dues coses del disseny de la validació. Primer, maxItems: 500 converteix en regla comprovada pel servidor el topall que a l'apartat 15.3 era només una convenció: l'array sense cota deixa de ser possible per descuit. Segon, els camps terme, material_id, camp i valor no són a required: cada tipus d'esdeveniment fa servir uns i no uns altres, i aquesta heterogeneïtat és precisament el que fa que aquesta dada visqui a MongoDB.

Per què desplegar primer amb warn. La col·lecció ja té dades escrites abans que existís la validació, i és pràcticament segur que algunes incompleixen: esdeveniments antics amb t guardada com a cadena, un tipus que es deia "consulta" abans de canviar-li el nom, contenidors generats en proves amb més de 500 elements. Amb validationAction: "error" aquestes escriptures començarien a fallar de cop en producció i a la ruta d'escriptura més freqüent del sistema (C6, el registre d'esdeveniments, amb exigència de menys de 10 ms). Amb warn, MongoDB accepta l'escriptura i anota l'incompliment al registre: durant uns dies es recullen els avisos, es quantifica el problema, es corregeixen els documents antics i les rutes de codi que els generen, i només llavors es passa a error amb la certesa que no es trencarà res.

I validationLevel: "moderate" complementa l'estratègia: mentre duri la neteja, les actualitzacions de documents que ja incomplien no es bloquegen, així que el procés de correcció pot treballar sense barallar-se amb la seva pròpia validació.

Aquesta ha estat la lliçó de disseny, i el seu contingut es resumeix així:

• L'ordre s'inverteix: en el model relacional es modela el domini i després es consulta; en el documental es parteix de la llista de consultes i es dissenyen documents que les resolguin en un sol accés. El mateix domini admet dissenys diferents segons el seu ús.
• Un agregat es llegeix junt, s'escriu junt i té una arrel. I sobretot: és la frontera de l'atomicitat. El que és dins del document canvia d'una peça; el que és fora necessita transacció o tolerància al desfasament.
• Incrustar o referenciar es decideix amb sis criteris: cardinalitat, si el fill es consulta per separat, volatilitat, mida enfront del límit de 16 MB, creixement acotat o il·limitat, i necessitat d'atomicitat conjunta.
• Un a pocs → incrustar. Un a molts → referenciar amb subconjunt al pare. Un a moltíssims → referenciar només des del fill, sense llista al pare.
• La duplicació és una eina, no un error, i cada camp duplicat pertany a una categoria: immutable (gratis), històric congelat (correcte per semàntica) o viu (exigeix propagació immediata, diferida o relectura). Duplica el que es mostra, mai el que es fa servir per decidir.
• Cinc patrons: referència estesa (copiar els pocs camps que es pinten), subconjunt (els N primers al pare), agrupació (sèries d'esdeveniments en contenidors per període, amb upsert i $setOnInsert), valor atípic (indicador per a la minoria desbordada) i camp calculat (guardar l'agregat i mantenir-lo amb $inc).
• Quatre antipatrons: arrays sense cota, documents gegants, col·leccions massives de documents diminuts i MongoDB fet servir com a base relacional a força de $lookup —el diagnòstic correcte del qual sol ser "això volia PostgreSQL"—.
• $jsonSchema recupera de manera voluntària i gradual part de la xarxa de seguretat perduda: tipus, rangs, camps obligatoris, patrons i valors tancats, amb validationLevel i validationAction regulables. No valida referències: la integritat referencial continua sent cosa de l'aplicació.
• El versionatge amb esquema_v permet evolucionar sense migració massiva, amb estratègies mandrosa, en segon pla o massiva. Conviu amb dues o tres versions i tanca les migracions.
• I el lliurable: cataleg (arrel el material, amb metadades lliures per tipus, valoracio calculada, ressenyes_destacades com a subconjunt i disponibilitat copiada de PostgreSQL), ressenyes (arrel la ressenya, amb material i soci com a referències esteses i vots incrustats per atomicitat) i activitat (arrel el conjunt soci-dia, amb patró d'agrupació, _id determinista, topall de 500 esdeveniments i índex TTL a dos anys).

Ja tenim les dues meitats del curs construïdes: biblioredb a PostgreSQL i bibliored a MongoDB, cadascuna amb el disseny que li correspon. A la lliçó 03-04, Comparació entre Bases de Dades Relacionals i No Relacionals, les posem cara a cara dimensió per dimensió i hi afegim les peces teòriques que hem anat ajornant: el teorema CAP sense el malentès habitual i el seu refinament PACELC, el contrast entre ACID i BASE, què significa realment la consistència eventual per al lector que acaba de publicar una ressenya, els nivells de consistència ajustables de MongoDB, i el matís decisiu que la frontera s'ha difuminat —PostgreSQL guarda documents amb jsonb i MongoDB té transaccions multidocument—. Tancarem amb una guia de decisió honesta, els mites més repetits desmuntats i el nom de l'arquitectura a la qual ha arribat BiblioRed: la persistència poliglota.