Har modelleret 348 tabeller i 34 Postgres‑skemaer

Situation. Kernen i platformen er et tæt maritimt domæne — professionelle, virksomheder, skibe, jobs, anmeldelser — og de refererer konstant til hinanden. En professionel sejler på skibe, arbejder for virksomheder og skriver anmeldelser; en virksomhed ejer skibe og slår jobs op. Næsten alle funktioner er databaseforespørgsler på tværs af det net, så hvor godt dataene er modelleret, afgør, hvor godt det meste af appen klarer sig, og hvor fornuftigt det er at udvide den.

Opgave. Det domæne skulle modelleres, så det forblev hurtigt og bevarede sin integritet, og så den næste entitetstype kunne tilføjes uden at skulle slås med skemaet.

Handling. Det er bygget op som normaliserede PostgreSQL‑skemaer, organiseret efter domæne — efterhånden 348 tabeller fordelt på 34 skemaer. De mange små, stabile enumerationer — statusser, typer, kategorier — blev til SMALLINT‑opslagstabeller, hvilket holder rækkerne kompakte og joins billige, i stedet for at der gemmes tekstkoder overalt. Entiteterne får UUID v7‑primærnøgler, så de er globalt unikke, men stadig tidsordnede i indekset. Én navnekonvention går igen overalt — tabelnavne i flertal inde i skemaer med navne i ental — og den anvendes uden undtagelse, hvilket som en ekstra gevinst undgår en masse kollisioner med reserverede ord. Og relationerne bæres af rigtige foreign keys og constraints, så integriteten er databasens opgave og ikke noget, applikationen skal huske.

Resultat. Resultatet er en datamodel, der er konsistent og hurtig og forudsigelig at arbejde i, fordi de samme regler gælder overalt — der er ingen særtilfælde at lære udenad. En ny funktion betyder som regel, at skemaet udvides i samme retning som det eksisterende og ikke imod det, og det er den eneste grund til, at 34 skemaer er en struktur og ikke et vildnis. Det er fundamentet, som resten af platformen står på.