Modellerte det maritime domenet i 348 normaliserte tabeller fordelt på 34 PostgreSQL‑skjemaer — fagfolk, selskaper, skip, stillinger, omtaler og resten — med SMALLINT‑oppslag og UUID v7‑nøkler.

Situasjon. Kjernen i plattformen er et tett maritimt domene — fagpersoner, selskaper, skip, stillinger, omtaler — og alt dette refererer stadig til hverandre. En fagperson seiler på skip, jobber for selskaper og skriver omtaler; et selskap eier skip og legger ut stillinger. Nesten hver funksjon er en spørring på tvers av det nettet, så hvor godt dataene er modellert, avgjør hvor godt det meste av appen yter og hvor ryddig den er å bygge videre på.

Oppgave. Domenet måtte modelleres slik at det forble raskt og beholdt integriteten, og slik at det å legge til neste entitetstype ikke betydde å kjempe mot skjemaet.

Handling. Det er lagt opp som normaliserte PostgreSQL‑skjemaer organisert etter domene — 348 tabeller fordelt på 34 av dem så langt. De mange små, stabile oppregningene — statuser, typer, kategorier — ble SMALLINT‑oppslagstabeller, som holder radene kompakte og join‑operasjonene billige i stedet for at tekstkoder lagres overalt. Entitetene får UUID v7‑primærnøkler, så de er globalt unike, men likevel tidsordnet i indeksen. Én navnekonvensjon gjelder overalt — tabellnavn i flertall inne i skjemaer med navn i entall — og brukes uten unntak, noe som på kjøpet unngår mange kollisjoner med reserverte ord. Og relasjonene holdes oppe av ekte fremmednøkler og skranker, så integriteten er databasens jobb, ikke noe applikasjonen må huske å gjøre.

Resultat. Det som kom ut av det, er en datamodell som er konsistent og rask, og forutsigbar å jobbe i fordi de samme reglene gjelder overalt — det finnes ingen spesialtilfeller å pugge. Å legge til en funksjon betyr som regel å utvide skjemaet langs de eksisterende linjene i stedet for å jobbe mot dem, og det er den eneste grunnen til at 34 skjemaer er en struktur og ikke et villniss. Det er grunnmuren resten av plattformen står på.