WeboracleArtikkelen forklarer forskjellen mellom primary keys, surrogate keys, natural keys, slugs og business keys. Den viser hvorfor stabile slugs er viktige i CMS-systemer, og hvordan unike constraints og rutiner reduserer feil.
En primary key er databasen sin tekniske garanti for entydighet. En slug eller business key er ofte systemets praktiske garanti for at mennesker, URL-er og integrasjoner finner riktig innhold. Begge deler må tas på alvor.
I en database er det vanlig å bruke numeriske ID-er som article_id, category_id og member_id. De er raske, stabile og enkle å bruke i relasjoner. Men de er ikke alltid gode i URL-er eller redaksjonelle arbeidsflyter. Derfor bruker mange publiseringssystemer også sluger.
Primary key er teknisk identitet
En primary key identifiserer én rad i en tabell. Den bør være unik, stabil og ikke-null. I praksis brukes ofte en autoinkrementert ID. Fordelen er at databasen får en enkel og effektiv nøkkel for joins, foreign keys og intern referanse.
En slik nøkkel bør sjelden vises som eneste offentlige identifikator. URL-en /article/30014 fungerer teknisk, men sier lite for brukeren og er mindre robust redaksjonelt enn en meningsbærende slug.
Slug er publisert identitet
En slug er en lesbar streng som ofte brukes i URL-er. Den kan være basert på tittelen, men bør behandles som eget datafelt. Tittelen kan endres uten at slug-en nødvendigvis bør endres. Hvis slug-en endres, kan gamle lenker slutte å fungere.
For et CMS er dette viktig. Eksterne lenker, søkemotorer, interne relaterte artikler og brukerens bokmerker kan alle peke på slug-en. Derfor bør sluger være unike innenfor riktig område, og endringer bør gjøres bevisst.
Business keys beskriver virkelige regler
En business key er en nøkkel som har betydning i domenet. Det kan være en e-postadresse for en bruker, en slug for en artikkel, en kode for en kategori eller et eksternt referansenummer. Slike nøkler kan være nyttige ved import og integrasjon.
Utfordringen er at business keys kan endre seg. En e-postadresse kan byttes. En kategori kan få nytt navn. Derfor bør de ikke ukritisk erstatte primary keys, men de bør likevel beskyttes med regler når systemet er avhengig av dem.
Unike constraints er dokumentasjon i databasen
Når en slug må være unik, bør databasen vite det. En unik indeks eller constraint gjør regelen eksplisitt. Det hindrer at to artikler får samme slug og konkurrerer om samme URL.
Dette er bedre enn å bare stole på at PHP-koden sjekker før lagring. Applikasjonen bør validere, men databasen bør beskytte viktige invariants.
Hva WEBoracle bør gjøre
For WEBoracle bør article_id fortsatt være teknisk identitet i databasen. Slug bør være publisert identitet for URL-er. Importfiler og SQL-patcher bør helst bruke begge deler i WHERE-klausulen når eksisterende artikler oppdateres:
WHERE article_id = 30014
AND slug = 'wo-article-014-hvorfor-slug-og-business-keys...';Det gir en ekstra sikkerhet. Hvis ID og slug ikke peker på samme rad, oppdateres ingenting. Det er bedre enn å skrive over feil artikkel.
Konklusjon
Primary keys, slugs og business keys løser ulike problemer. Primary keys gir databasen stabil teknisk identitet. Slugs gir brukeren og URL-systemet lesbar identitet. Business keys gjør import og integrasjon mer forståelig. Et modent CMS respekterer alle tre.