Normalisering og duplisering blir ofte fremstilt som motsetninger der bare én side er riktig. I praksis trenger et CMS begge deler, men på ulike steder og av ulike grunner.

Diagram som viser normaliserte tabeller og kontrollert duplisert visningsdata
God datamodellering handler om å vite når data skal deles, og når de bør fryses eller dupliseres.

Normalisering handler om å lagre data slik at samme fakta ikke finnes unødvendig mange steder. Det reduserer inkonsistens og gjør oppdateringer enklere. Duplisering betyr at samme eller avledet informasjon lagres flere steder. Det kan være farlig hvis det skjer tilfeldig, men nyttig hvis det gjøres bevisst.

Når normalisering er riktig

Normalisering passer godt for data som har en klar identitet og brukes flere steder. Kategorier, roller, medlemmer og tagger bør normalt ligge i egne tabeller. Da kan én kategori brukes av mange artikler uten at kategorinavnet må skrives inn på nytt i hver rad.

Når duplisering kan være riktig

Noen data bør fryses på tidspunktet de brukes. Hvis en artikkel viser forfatternavn, kan det være riktig å hente det fra medlemstabellen. Men en faktura, logg eller historisk rapport bør kanskje lagre navnet slik det var da hendelsen skjedde. Ellers kan historikken endre seg når brukerprofilen endres.

Ytelse og lesemønster

Et CMS leser ofte mye mer enn det skriver. Det kan friste å duplisere data for å gjøre visninger raskere. Det kan være riktig, men bør først vurderes mot indekser, smalere spørringer og caching. Duplisering bør løse et kjent problem, ikke være førstevalg.

Den farlige mellomtingen

Den største risikoen er ubevisst duplisering. Det skjer når et felt kopieres fordi det er praktisk i øyeblikket, uten regler for hvem som eier sannheten. Da kan kategori, tittel eller status få ulike verdier i ulike tabeller.

Bruk tydelig eierskap

Når data dupliseres, bør systemet vite hvor originalen ligger. Hvis categories.name er sannheten, bør kopierte kategorinavn i rapporter eller cache behandles som avledet data. Hvis et felt er historisk snapshot, bør det dokumenteres som nettopp det.

WEBoracle-vurdering

For WEBoracle bør kategorier, tagger, roller og medlemmer normaliseres. Artikkel- og tutorialvisninger kan derimot ha avledede felt som summary, excerpt og main_image_url fordi de hjelper frontend og redaksjonell presentasjon. Slike felt er ikke feil, men de må ha tydelig formål.

Konklusjon

Normalisering gir orden. Kontrollert duplisering kan gi ytelse, historikk og enklere visning. Forskjellen på god og dårlig praksis ligger i bevisstheten: data bør ikke kopieres fordi man mangler plan, men fordi systemet faktisk trenger det.

Kilder og videre lesning

  1. PostgreSQL Documentation: Table Basics and Constraints
  2. PostgreSQL Documentation: Constraints
  3. MySQL 8.4 Reference Manual: Optimization and Indexes