WeboracleArtikkelen forklarer hvorfor kategoritabeller bør modelleres som sentrale domenedata. Den tar for seg datakvalitet, slugs, hierarkier, innholdstyper, indekser og konsekvensene av å blande menystruktur med innholdsstruktur.
Kategorier ser enkle ut i et kontrollpanel, men i en databasebasert publiseringsløsning er de ofte langt viktigere enn menyvalg. De beskriver hvordan innholdet er organisert, hvordan brukeren finner fram, og hvordan systemet kan filtrere, indeksere og anbefale innhold.
Det er fristende å tenke på en kategoritabell som en enkel liste: navn, slug og kanskje sortering. Det fungerer i starten, men blir fort svakt når systemet får artikler, scripts, tutorials, forumtråder og moduler som alle trenger struktur. Da er ikke kategorien lenger pynt. Den er en del av domenet.
Kategori er ikke det samme som meny
En meny er en presentasjon. Den viser brukeren en bestemt vei inn i innholdet. En kategori er en klassifisering. Den beskriver hva innholdet handler om, og kan brukes av flere deler av systemet samtidig. Hvis disse to blandes, blir databasen vanskelig å bruke over tid.
Et CMS kan for eksempel ha kategorien PHP API og integrasjoner. Den kan vises i menyen, brukes som filter i scriptbiblioteket, kobles til tutorials og brukes i relaterte artikler. Hvis kategorien bare er en menytekst, mister systemet muligheten til å forstå den på tvers av innholdstyper.
Slugs gjør kategorien stabil i URL-er
En god kategoritabell trenger som regel både et menneskelig navn og en maskinvennlig slug. Navnet kan endres for språk, tone eller presisjon. Slug-en bør være mer stabil, fordi den ofte brukes i URL-er og interne koblinger.
Dette er grunnen til at en kategori ikke bør identifiseres i frontend med ren tekst. Tekst kan få ny skrivemåte. En slug kan fungere som en forutsigbar nøkkel i ruter, filtre og SQL-spørringer.
Hierarkier krever tydelige regler
Mange nettsteder starter med flate kategorier. Etter hvert kommer behovet for underkategorier. Da dukker felt som parent_id opp. Det er nyttig, men krever regler. Hvor dype kan hierarkiene bli? Kan en kategori brukes på flere innholdstyper? Skal en overkategori telle innhold fra underkategorier?
Uten slike regler blir kategoritabellen en blanding av navigasjon, fagområde og teknisk snarvei. Det virker uskyldig, men skaper ofte feil i brødsmuler, filtrering, relaterte lister og søk.
Kategorier bør støtte datakvalitet
En kategoritabell bør ha nok struktur til å hindre inkonsistente data. Det kan bety unike slugs, fornuftig sortering, tydelig typefelt og en bevisst relasjon til innholdstabellene. I MySQL kan indekser brukes til å gjøre oppslag raskere, men også til å støtte unike verdier der det er riktig.
For WEBoracle betyr dette at kategorier ikke bare bør opprettes fordi en meny trenger et punkt. De bør opprettes fordi systemet trenger et faglig område som kan brukes på tvers av artikler, scripts og tutorials.
Skille mellom innholdstype og fagområde
En vanlig feil er å la kategorien gjøre for mange jobber. Article, Tutorial og Script er innholdstyper. PHP, SQL, HTML og CSS3 er fagområder. En god modell bør ikke tvinge samme felt til å bety begge deler.
Hvis kategorien både forteller hva innholdet er og hvilket fagområde det tilhører, blir filtrering uklar. En bedre løsning er å la tabeller og relasjoner fortelle innholdstype, mens kategorier og tagger beskriver faglig innhold.
Konklusjon
Kategoritabeller er små, men viktige. De påvirker URL-er, navigasjon, filtrering, søk, relaterte artikler og kontrollpanelets forståelse av innholdet. Derfor bør de behandles som domenedata. En god kategorimodell gjør nettstedet lettere å utvide. En dårlig kategorimodell gjør hver ny innholdstype tyngre å håndtere.