Database

En database er et system til at gemme og organisere oplysninger, så de kan findes og ændres effektivt. På en hjemmeside kan den indeholde sider, brugere, indstillinger, formularer, produkter, lager, ordrer og meget andet.

I WordPress ligger mediefiler typisk som filer på serveren, mens beskrivelser, relationer og indstillinger ligger i databasen. Derfor er det ikke nok at kopiere billeder og tema, hvis en løsning skal flyttes eller gendannes.

WordPress bruger normalt MySQL eller MariaDB. Data er fordelt i tabeller med forskellige roller. En tabel indeholder eksempelvis indlæg og sider, en anden metadata, og andre håndterer brugere, kommentarer eller indstillinger. Plugins kan oprette egne tabeller eller bruge de eksisterende.

En database er ikke noget, de fleste redaktører behøver at arbejde direkte i. Et CMS giver et sikkert lag med formularer og rettigheder. Direkte adgang er relevant ved fejlfinding, migrering, integration eller specialudvikling, men den kræver stor omhu.

På en webshop er databasen tæt på forretningens drift. Nye ordrer, betalingstilstande, lager og kundedata ændres løbende. Derfor skal backup, ydeevne og adgangskontrol planlægges mere præcist end på en enkel præsentationsside.

Start med at kende datamodellen, før noget ændres. Find ud af hvilke tabeller og felter systemet bruger, og hvordan oplysninger hænger sammen. Et produkt kan være koblet til varianter, priser, lager og kategorier gennem flere relationer.

Brug platformens API eller administrationsfunktioner, når de kan løse opgaven. En dokumenteret API håndterer ofte validering og relationer, som en rå SQL-ændring ellers kan overse. Direkte databasearbejde bør være et bevidst valg, ikke den hurtigste genvej.

Tag altid en backup før import, søg-og-erstat eller strukturændringer. På aktive systemer bør du også tage højde for nye data, der kommer ind under arbejdet. En kopi fra klokken 08 er hurtigt forældet, hvis butikken modtager ordrer hele dagen.

Udfør større ændringer i et stagingmiljø. Test både de synlige sider og bagvedliggende funktioner. En ændring kan se korrekt ud på forsiden, men have brudt søgning, integrationer eller planlagte opgaver.

Hold databasen ved lige. Gamle revisionskopier, midlertidige data, forældede plugin-tabeller og store logfiler kan gøre backup og forespørgsler tunge. Ryd kun op med dokumentation og en kopi, fordi “ubrugt” ikke altid kan afgøres ud fra navnet.

Begræns adgang. Brug separate databasebrugere med de nødvendige rettigheder, stærke adgangskoder og sikre forbindelser. Del ikke hovedlogin i e-mails eller dokumenter, og fjern adgange, når en leverandør ikke længere arbejder på løsningen.

En virksomhed ændrer domæne på sin WordPress-side. Mange interne links og billedadresser ligger gemt i databasen med det gamle domæne. En simpel tekstlig søg-og-erstat virker fristende, men nogle WordPress-data er serialiserede og kan blive ødelagt af en forkert metode.

Udvikleren tager først en fuld kopi og opretter staging. Derefter bruges et værktøj, der forstår WordPress-datastrukturen. Ændringen køres på en begrænset tabelmængde, og antallet af fund dokumenteres før og efter.

Efter udskiftningen testes sider, menuer, widgets, formularer og mediebibliotek. Der køres også kontrol for gamle adresser. Enkelte links ligger i hårdkodede temafiler og skal rettes uden for databasen.

Når ændringen skal gennemføres i produktionsmiljøet, vælges et tidspunkt med lav aktivitet. Siden sættes kort i vedligeholdelse, en ny backup tages, og den testede procedure gentages. Det begrænser risikoen for, at data ændrer sig midt i arbejdet.

Virksomheden kan læse guiden om hvad et CMS er for at forstå forskellen mellem redaktørens grænseflade og de data, systemet faktisk gemmer bagved.

Den største faldgrube er en masseændring uden præcis afgrænsning. En SQL-forespørgsel uden korrekt WHERE-betingelse kan opdatere alle rækker. Test først med en SELECT, kontrollér antal resultater, og arbejd på en kopi.

En anden fejl er at slette tabeller fra gamle plugins uden at undersøge dem. Pluginet kan stadig levere data til rapporter, formularer eller integrationer, selv om det ikke er synligt i menuen. Dokumentér afhængigheder før oprydning.

Pas på persondata i testmiljøer og backups. En kopi af produktionsdatabasen kan indeholde kunder, adresser og ordrer. Adgang, opbevaring og anonymisering skal håndteres lige så omhyggeligt som i produktionssystemet.

Det er også risikabelt at optimere databasen med tilfældige plugins. Nogle rydder revisioner eller transients sikkert, andre sletter data aggressivt. Vurder præcis hvilke tabeller og poster værktøjet ændrer.

Endelig kan fejlen ligge et andet sted. En langsom side skyldes ikke automatisk en “tung database”. Tema, eksterne scripts, ukorrekt cache eller langsom hosting kan være vigtigere. Mål før du ændrer.

En relationel database organiserer data i tabeller og forbindelser. Det passer godt til eksempelvis kunder, ordrer og produkter, hvor oplysninger skal kunne kobles og søges. Andre databasetyper bruges til andre behov.

WordPress' fleksible metadata gør det let for temaer og plugins at gemme ekstra felter, men store og dårligt indekserede datasæt kan blive langsomme. Specialløsninger kan have gavn af egne tabeller, når datamængde og forespørgsler kræver det.

Databasepræfikset i WordPress er ikke en stærk sikkerhedsforanstaltning i sig selv. Den vigtigste beskyttelse er opdateret software, begrænset adgang, sikre legitimationsoplysninger, firewall og god drift.

En eksport er ikke altid en fuld backup. En CSV med produkter indeholder måske ikke variationer, billeder, relationer og indstillinger. Definér formålet: rapportering, flytning, arkivering eller komplet gendannelse.

Ved integrationer bør ejerskab af data være tydeligt. Er webshoppen, økonomisystemet eller CRM-systemet kilden til kundestatus og lager? Uden en source of truth kan systemerne overskrive hinanden med forældede oplysninger.

Databasen bør overvåges som en del af den samlede løsning. Fejl i planlagte jobs, stigende tabeller eller gentagne langsomme forespørgsler kan opdages, før brugerne oplever et stort problem.

Skriv den ønskede ændring som en regel med eksempel: “Alle produkter i kategori X skal have felt Y sat til Z.” Det gør det lettere at kontrollere, om forespørgslen rammer præcist.

Kør en optælling og gem et udsnit af de berørte rækker. Hvis antallet overrasker, stop og undersøg. Den bedste fejl er den, der opdages før UPDATE eller DELETE.

Planlæg rollback. Ved præcise ændringer kan det være en modsat forespørgsel; ved større ændringer kan det være gendannelse. På aktive systemer skal nye data siden kopien håndteres særskilt.

Afslut med kontrol i både database og brugerflade. Data kan være teknisk ændret, men stadig vises forkert på grund af cache eller kode.

Når databasen mistænkes for at være langsom, bør problemet måles med forespørgsler, svartider og konkrete sider. En stor tabel er ikke automatisk langsom, og en lille tabel kan give problemer uden de rigtige indeks.

Brug logning og profileringsværktøjer i et kontrolleret miljø. De kan vise gentagne forespørgsler, manglende indeks eller plugins, der henter unødigt mange rækker. Slå ikke tung debug til permanent på live.

Kontrollér også autoloadede indstillinger i WordPress. Mange store poster, som indlæses på hver side, kan påvirke ydeevnen. De bør dog ikke slettes uden at kende ejeren og funktionen.

Database-cache og object cache kan forbedre svartider, men de skjuler ikke en dårlig forespørgsel for evigt. Optimer først mønsteret, og brug cache som et bevidst lag.

Efter en ændring skal målingen gentages under sammenlignelige forhold. Ellers bliver “det føles hurtigere” den eneste dokumentation, og næste problem starter fra nul.

Ved rapportering og fejlsøgning bør der udtrækkes mindst mulige datamængde. En anonymiseret kopi eller et begrænset udsnit er ofte nok og reducerer risikoen ved at sende hele kundedatabasen rundt.

Beskriv felter, datoformater og relationer sammen med eksporten. Ellers kan den næste modtager tolke tomme værdier, statuskoder eller beløb forkert og bygge en ny fejl oven på de gamle data.

På en almindelig hjemmeside kan databasen også rumme formularhenvendelser, medlemsdata eller flersprog. Selv uden webshop bør adgange og eksport derfor behandles som forretningskritiske data.