Planlegge en MySQL-database for nettapplikasjoner

Når tre ansatte bestiller varer parallelt om morgenen, en kunde sjekker leveringsstatus, og administrasjonen lager en faktura, vises ikke kvaliteten til en applikasjon i designet. Den vises i om alle ser nøyaktig samme, korrekte datastatus. Å planlegge en MySQL-database for en nettapplikasjon betyr derfor ikke å lage tabeller så raskt som mulig. Det betyr å forstå reelle arbeidsflyter presist nok til å sikre at data forblir pålitelige selv under belastning, ved feil, og etter hvert som virksomheten vokser.

Spesielt i interne plattformer, lager- og ordreprosesser, eller kundevendte portaler, blir databasen ofte håndtert for sent. Først bygges grensesnittet, deretter legges felt til, fulgt av unntak. Det fungerer for en prototype. I drift resulterer dette i duplikerte datasett, uklare tilstander, og rapporter ingen lenger stoler helt på.

Planlegge en MySQL-database for nettapplikasjoner: start med arbeidsflyten

Det første utkastet bør ikke starte med kolonnenavn, men med en konkret arbeidssituasjon. Ta varemottak: en leveranse ankommer, tildeles en leverandør og en ordre, mengder kontrolleres, en lagerplass tildeles, og lageret endres. Avhengig av operasjonen krever denne prosessen i tillegg bilder, en kvalitetskontroll, en sperrestatus, eller en sporbar korreksjon. Fra denne arbeidsflyten vokser de funksjonelle objektene frem. Typiske eksempler er artikler, leverandører, ordrer, posisjoner, lagerplasser, lagerbevegelser, og brukere.

Skillet mellom et objekt og en hendelse er avgjørende. En artikkel beskriver hva noe er. En lagerbevegelse dokumenterer at en mengde endret seg på et bestemt sted på et bestemt tidspunkt. Å blande begge i én tabell fører raskt til tap av sporbarhet.

Noen vanskelige spørsmål hjelper for hvert objekt: hva er den unike identiteten? Hvilken informasjon kan endres? Hvem kan endre den? Hvilke data må bevares historisk? Og hvilke regler gjelder når to personer jobber samtidig? Disse spørsmålene forhindrer senere improvisasjon bedre enn en lang liste med angivelig komplette databasefelt.

Datamodellen bør uttrykke regler

En database er ikke bare lagring for skjemainndata. Den bør selv håndheve sentrale regler. Hvis hver lagerbevegelse må tilhøre nøyaktig én artikkel og én lagerplass, hører fremmednøkler hjemme i modellen. Hvis et eksternt ordrenummer bare kan forekomme én gang per tenant, kreves en unik indeks. Hvis en posisjon aldri bør eksistere uten en hovedordre, må denne relasjonen modelleres tydelig.

MySQL 8 med InnoDB gir et solid grunnlag for dette: transaksjoner, fremmednøkler, låsemekanismer, og konsistente endringer på tvers av flere tabeller. Ved skriving av en bevegelse, gjeldende lager, og inspeksjonslogg under en varemottaksbokføring bør dette skje som én sammenhengende transaksjon. Hvis ett trinn feiler, skal ingen halvferdig operasjon bli stående.

Men ikke alle regler hører hjemme i databasen. Godkjenninger, kompleks prislogikk, eller rolleavhengige prosesstrinn plasseres ofte bedre i applikasjonslogikken fordi de endres raskere funksjonelt. Grensen er pragmatisk: regler hvis brudd permanent skader data bør sikres så nært dataene som mulig. Regler som endres ofte eller er sterkt avhengige av konteksten, krever godt testet applikasjonskode.

Ikke forveksle historikk med gjeldende verdier

En vanlig feil er å bare lagre gjeldende lager eller gjeldende status. Det holder til noen spør hvorfor mengden endret seg i går eller hvem som tilbakestilte en ordre. For operative systemer er en historikk over bevegelser eller hendelser ofte mer verdifull enn ett enkelt overskrivbart felt.

Dette betyr ikke at hver klikkbevegelse må logges permanent. Forretningsrelevante endringer bør logges: statusendringer, mengdejusteringer, korreksjoner, godkjenninger, og tildelinger. En god revisjonspost inneholder et tidsstempel, brukeren eller systemprosessen, forrige og ny verdi, og en forståelig begrunnelse når arbeidsflyten krever det. Dette gjør det mulig å avklare feil uten å måtte lete gjennom e-poster, papirlister, eller databasebackuper.

Velg nøkler, datatyper, og navnekonvensjoner bevisst

Tekniske beslutninger virker små, men former vedlikehold og integrasjoner i årevis. For interne primærnøkler er BIGINT-verdier med automatisk tildeling ofte et nøkternt, lett håndterbart valg. UUID-er kan være fornuftige når data oppstår offline, flere systemer skriver uavhengig, eller eksterne grensesnitt ikke bør eksponere sekvensielle ID-er. De koster imidlertid mer lagringsplass og krever litt mer oppmerksomhet med indekser og sortering.

Pengebeløp bør lagres som DECIMAL, ikke FLOAT eller DOUBLE. Mengder trenger også en funksjonelt passende presisjon: artikkelantall er ofte heltall, mens vekter og lengder ikke er det. Tidsstempler bør håndteres enhetlig, helst internt i UTC, mens grensesnittet viser den lokale tidssonen for operasjonen. Spesielt ved skiftbytter og sommertid forhindrer dette vanskelig oppdagbare avvik.

Navn bør også være kjedelige og entydige. order_items eller inventory_movements er mer nyttige enn kreative forkortelser som bare det opprinnelige prosjektteamet forstår. Konsekvente entalls- eller flertallsformer er mindre viktige enn konsistens i seg selv. Like fornuftige er felt som created_at, updated_at, og, ved behov, deleted_at. En myk sletting er likevel ikke en standardforpliktelse. For juridisk eller operativt relevante poster er en ren kansellering vanligvis bedre enn et usynlig slettet datasett.

Indekser følger faktiske spørringer, ikke gjetning

En indeks kan akselerere et søk massivt, men gjør skriveoperasjoner mer komplekse og bruker lagringsplass. Derfor er "en indeks på hvert felt" ingen strategi. De viktigste spørringene bør etableres tidlig: åpne ordrer for en kunde, bevegelser for en artikkel innenfor en periode, lager per lagerplass, eller nylig endrede poster for et grensesnitt.

Rekkefølgen på sammensatte indekser har betydning her. Hvis applikasjonen regelmessig søker etter tenant_id, status, og created_at, er en sammensatt indeks i nettopp denne rekkefølgen ofte fornuftig. Om den faktisk passer, vises av utførelsesplanen via EXPLAIN, ikke av magefølelse. Databaser blir ikke raske av spektakulære triks, men av observerbare spørringer, matchende indekser, og realistisk testede datavolumer.

For voksende tabeller lønner det seg med en tydelig oppbevaringsstrategi. Må tekniske logger ligge i den primære produksjonsdatabasen i fem år? Ikke nødvendigvis. Forretningsposter, bevegelser, og inspeksjonsbevis krever andre oppbevaringsperioder enn feilsøkingsinformasjon. Arkivering er ikke et tegn på et svakt system, men en bevisst driftsbeslutning.

Flerbrukerdrift krever transaksjoner og tydelige tilstander

I en nettapplikasjon får flere forespørsler tilgang til de samme dataene samtidig. Dette er normalt i daglig lagerdrift, ikke et unntak. To ansatte kan bestille det samme lageret mens en import lager nye ordrer. Uten transaksjoner og målrettet låsing er det risiko for tapte endringer eller negative lagerbeholdninger som først blir synlige uker senere.

For kritiske operasjoner bør det være tydelig hvilke data som leses og skrives innenfor en transaksjon. Noen ganger er en atomær oppdatering tilstrekkelig, som lager som bare endres hvis tilgjengelig mengde er nok. I andre tilfeller er en radlås fornuftig, slik at en operasjon kan kontrollere datatilstanden på en kontrollert måte og endre den etterpå. Lange transaksjoner er derimot problematiske: de blokkerer annet arbeid og øker risikoen for konflikter.

Like viktig er et begrenset sett med funksjonelle tilstander. En ordre bør ikke være "åpen," "delvis levert," og "manuelt behandlet" samtidig på grunn av vedlikehold av motstridende felt. Definerte statusoverganger forenkler grensesnitt, rapporter, og automatiseringer. Unntak kan tillates, men bør navngis og dokumenteres.

Planlegg sikkerhet, tenanter, og drift fra begynnelsen

Applikasjonen bør bruke en dedikert databasebruker for MySQL med minimale rettigheter. Skrivetilgang for nettapplikasjonen betyr ikke at denne brukeren trenger å kunne slette tabeller eller endre brukerrettigheter. Administrative kontoer hører ikke hjemme i produksjonskonfigurasjonsfiler og aldri i et repositorium.

Når flere kunder, steder, eller selskaper jobber innenfor én applikasjon, er tenant-isolasjon en arkitektonisk beslutning, ikke en filterbetingelse lagt til i ettertid. En delt database med en tenant_id kan være effektiv og lett å vedlikeholde, men krever konsistente kontroller i hver spørring og tydelige regler for indekser. Separate databaser gir sterkere isolasjon, men øker innsatsen ved oppdateringer, evalueringer, og drift. Hvilken variant som passer, avhenger av personvernkrav, datavolum, og forretningsmodell.

Sikkerhetskopier er bare sikkerhetskopier når en gjenoppretting er testet. En fastsatt rytme for sikkerhetskopiering, oppbevaring, og gjenoppretting er nødvendig. Likeledes hører overvåking av lagringsplass, trege spørringer, og mislykkede jobber, sammen med dokumenterte oppdateringer, til systemet. MySQL 8, PHP 8.4, og moderne nettapplikasjoner kan driftes godt på lang sikt hvis avhengigheter, tilgangsopplysninger, og utrullingstrinn ikke bare finnes i hodet til én utvikler.

En fornuftig plan før den første dagen i produksjon

Før implementering bør det finnes en kompakt datamodell med eksempelarbeidsflyter. Dette inkluderer nøkkeltabeller og relasjoner, statusregler, rettigheter, forventede spørringer, grensesnitt, og et konsept for sikkerhetskopier og revisjonslogger. Denne planen trenger ikke å være hundre sider lang. Den må fange opp beslutninger som senere ville vært kostbare å rette opp.

Hos softify.pro starter databaseplanlegging derfor med menneskene som bestiller, kontrollerer, plukker, eller løser unntak. Hvis et eksisterende regneark pålitelig kartlegger en håndterbar prosess, kan det forbli den riktige løsningen. Hvis flere personer jobber samtidig, poster oppstår, og feil må være sporbare, fortjener databasen derimot samme planleggingsinnsats som grensesnittet. Den beste arkitekturen er til syvende og sist den som forenkler arbeidsdagen og som fortsatt kan endres transparent om to år.