Databasedesign og optimalisering

De fleste trege databaser mangler den åpenbare indeksen

Når en applikasjon blir tregere etter hvert som den vokser, er årsaken vanligvis ikke serveren eller databasemotoren. Det er en håndfull spørringer som skanner hele tabeller fordi ingen indeks matcher måten de søker på. En spørring som tok 20 millisekunder med 1 000 rader, kan ta sekunder med en million, og ingen merker det før kundene gjør det.

Vi starter fra bevis: databasens egne statistikker over hvilke spørringer som kjøres oftest og tar lengst tid. Det peker vanligvis på en kort liste med tiltak, som en indeks på kolonnene et vanlig filter bruker, en spørring skrevet om for å unngå å laste hele tabeller, eller en manglende kobling mellom tabeller som tvinger fram gjentatte oppslag. Vi måler hver spørring før og etter, slik at forbedringen er synlig i stedet for påstått.

Begrensninger stopper dårlige data ved døren

Mange databaser er avhengige av at applikasjonen holder dataene rene. Appen sjekker at en e-post er unik, at en ordre tilhører en reell kunde, at en mengde ikke er negativ. Så hopper en annen app, et importskript eller en rask manuell retting over disse sjekkene, og duplikater og foreldreløse poster sniker seg inn. Rapporter begynner å si ulike ting, og ingen er sikre på hvilket tall som er riktig.

Et godt utformet skjema håndhever de viktige reglene selv: unike begrensninger, fremmednøkler, sjekkbegrensninger og fornuftige standardverdier. Alt som skriver til databasen, må følge dem. For et eksisterende system finner vi hvor data allerede har gått galt, planlegger oppryddingen og legger deretter til begrensningene så det ikke skjer igjen.

• Unike begrensninger på ting som ikke må gjentas, som e-post eller fakturanummer
• Fremmednøkler så poster ikke kan peke på noe som ikke finnes
• Sjekk begrensninger for verdier som må holde seg innenfor området
• Indekser valgt fra reelle spørringsmønstre, ikke lagt til overalt