WeboracleArtikkelen forklarer hva som kan gå galt ved blind import av store SQL-filer, og hvordan utviklere kan redusere risiko med backup, testimport, transaksjoner, tegnsett, idempotens og verifikasjon.
En stor SQL-fil ser ofte uskyldig ut: åpne Workbench, kjør import, vent på grønt lys. Problemet er at en SQL-import kan endre store deler av systemet på kort tid. Hvis filen kjøres blindt, oppdager man ofte feilene først etterpå.
SQL-filer brukes til backup, flytting mellom miljøer, patcher, seed-data og masseoppdatering. Alle disse formålene er legitime, men de har ulik risiko. En full dump kan inneholde DROP TABLE, CREATE TABLE og store mengder data. En patch bør helst være smalere og mer presis.
Første feil: feil miljø
Den mest brutale feilen er å kjøre riktig fil på feil database. Det kan skje når utvikling, staging og produksjon ligger nær hverandre i samme verktøy. Derfor bør SQL-filer merkes tydelig, og kritiske patcher bør inneholde kommentarer som beskriver hvilket system og hvilken dato de gjelder.
Tegnsett kan ødelegge innhold
For innholdssystemer er tegnsett viktig. Norske tegn, typografiske anførselstegn, kodeeksempler og HTML kan bli skadet hvis klient, fil og database ikke bruker samme tegnsett. Derfor bør patchfiler ofte starte med SET NAMES utf8mb4;, slik at forbindelsen tolker innholdet riktig.
Rekkefølge betyr mye
Relasjonelle databaser har avhengigheter. Kategorier kan måtte finnes før artikler. Artikler kan måtte finnes før taggkoblinger. Brukere kan måtte finnes før innhold knyttes til member_id. Hvis importen gjør ting i feil rekkefølge, kan foreign keys eller logiske avhengigheter stoppe kjøringen.
Store filer skjuler små feil
Jo større filen er, jo vanskeligere er det å se hva den faktisk gjør. En liten syntaksfeil, en manglende apostrof eller en feil slug kan ligge langt nede i filen. Derfor er det tryggere å dele innholdsoppdateringer i batcher med tydelig changelog og verifikasjonsspørringer.
LOAD DATA er kraftig, men krever kontroll
MySQL har egne mekanismer for å laste data, blant annet LOAD DATA. Det kan være effektivt for store datamengder, men krever presis kontroll på filformat, skilletegn, tegnsett og kolonnerekkefølge. For redaksjonelle oppdateringer er vanlige UPDATE- og INSERT-patcher ofte enklere å lese og revidere.
Verifikasjon bør være del av filen
En god SQL-patch bør ikke bare gjøre endringer. Den bør også hjelpe deg å kontrollere resultatet. Nederst i filen kan man legge inn SELECT-spørringer som viser oppdaterte rader, tekstlengde, bildebaner og taggantall.
SELECT article_id, title, CHAR_LENGTH(body) AS body_chars
FROM articles
WHERE article_id IN (30011, 30012, 30013);Konklusjon
Å importere SQL blindt er en unødvendig risiko. En trygg import har backup, riktig miljø, riktig tegnsett, tydelig rekkefølge, smal endringsflate og verifikasjon. For små produksjonssystemer er dette ofte forskjellen på en kontrollert oppdatering og en lang kveld med feilretting.