Computerworld News Service: SQL-udviklere på alle platforme har prøvet at være fanget i en dårlig cyklus, hvor de gentager de samme fejl igen og igen.
Det skyldes ikke mindst, at database-området stadig er relativt umodent. Du kan læse mere om SQL her.
Database-producenterne arbejder på sagen, men har i bund og grund fokus på de store udviklingstemaer og ikke på det daglige arbejde.
Det betyder, at opgaver som ressourcestyring, pladsstyring og hastighed fortsat udgør en udfordring for SQL-udviklerne - uanset om de koder på SQL Server, Oracle, DB2, Sybase, MySQL eller en anden platform.
En del af problemet er, at der ikke findes nogen 'magic bullet'.
Typisk finder en udvikler sin egen løsning på problemerne og holder sig til den.
Det er klart, at SQL-udviklerne ikke skal blive til administratorer, men de bliver på den anden side nødt til at tage produktions-indgangsvinklen med i betragtningerne, når de skriver deres kode.
Gør de ikke det i den indledende udviklings-fase, vil de blive nødt til at gøre det senere. Imens vil brugerne stå med håret i postkassen.
En kunst og en videnskab
Der er gode grunde til, at vi normalt siger, at det både er en kunst og en videnskab at tune en database.
Mest fremtrædende er, at der kun findes ganske få nagelfaste regler, der gælder over hele paletten.
De problemer, som du kunne løse på et system, er sikkert ikke problemer på et andet og vice versa.
Der er med andre ord ikke nogen endegyldig sandhed, men der findes gode principper, og dem kan du se nogle stykker af herunder.
1: Brug ikke UPDATE i stedet for CASE
Dette er et meget udbredt problem, og selvom det ikke er svært at få øje på, overser mange udviklere det ofte, fordi anvendelsen af UPDATE har et naturligt flow, som virker logisk.
Et eksempel: Du indsætter data i en temporær tabel med henblik på at vise en bestemt værdi. Måske trækker du data fra din kunde-base, hvor du vil have alle kunder med ordrer for mere end 100.000 kroner mærket med "foretrukken".
Derfor indsætter du data i din table og kører en UPDATE for at sætte kunderangeringen til "foretrukken" for alle kunder, der har mere end 100.000 kroner i ordrer.
Men UPDATE logges, hvilket betyder, at data skrives to gange for hver enkelt skriv til tabellen.
En løsning er at anvende en inline CASE i SQL-query'en. Hermed tester man alle rækker for ordrebeløb, og kunderangeringen "foretrukken" sættes, inden data skrives i tabellen.
Performance-forbedringen kan være overvældende. Prøv det.
Må du genanvende kode? Se svaret her
2: Genanvend ikke kode uden at tænke dig om
Det er meget nemt og fristende at kopiere andres kode, fordi du ved, at det kan trække de data, som du har brug for.
Problemet er bare, at den kopierede kode ofte læser flere data, end du faktisk har brug for. Udviklere gider for det meste ikke bekymre sig om at trimme koden ned, så de ender ofte med meget store mængder data.
Du kan derfor høste meget store performance-forbedringer, hvis du trimmer den kopierede kode til dit eksakte behov.
3: Begræns antallet af kolonner
Det er faktisk det samme som nummer 2 herover, blot drejer det sig særskilt om kolonner.
Det er alt for nemt at kode alle queries med SELECT* fremfor at liste alle kolonnerne hver for sig.
Problemet er (igen), at det læser flere data, end du har brug for. Det er typisk, at en udvikler kører en SELECT* i en tabel med 120 kolonner og millioner af rækker, men ender med blot at anvende tre eller fire af dem.
Sker det, læser du ikke blot flere data, end du har brug for. Du suger også kræfter væk fra andre processer.
4: Hold kursen lige uden slinger i valsen
Igen en meget udbredt fejl. En udvikler skriver en procedure til at trække data ud fra en tabel med hundrede af millioner af rækker.
Udvikleren skal hente data om alle kunder, der bor i Californien og har indtjening på mere end 100.000 kroner. Så han finder først alle kunder med domicil i Californien og smider resultatet ind i en temporær tabel.
Dernæst finder han kunder med indtjening over 100.000 kroner og sætter resultatet ind i en anden temporær tabel.
Til slut sætter han de to tabeller sammen for at hente slut-resultatet.
Den fremgangsmåde holder bare ikke. Søgningen skal gennemføres i én query fremfor at køre en slingrekurs gennem den meget store tabel.
Et andet scenarie er, når en delmængde af data i en stor tabel skal bruges i flere omgange i en større operation. Her vil hvert enkelt skridt medføre en query mod den store tabel.
Undgå dette ved at køre en query for at få fat i delmængden og arbejd efterfølgende videre på delmængden af data fremfor at forespørge på den store tabel hver gang.
Og hvad med pre-stage data
5: Vær klar over det, når du kører temporære tabeller
Dette er lidt sværere at håndtere, men lykkes det, kan du høste meget store performance-forbedringer.
Du kan køre temporære tabeller i mange situationer - ikke mindst til at minimere processor-kravene, når du arbejder med store tabeller.
Du kan forbedre performance ved at trække de data, du har brug for, ud af de store tabeller og over i en temporær tabel og arbejde med den i stedet.
6: Pre-stage data
Dette er en gammel teknik, som ofte bliver overset. Hvis du har en report eller en procedure (eller begge dele), der begge skal køre ens 'joins' af store tabeller, kan det svare sig at sammenkøre tabellerne forud i en pre-stage.
Det betyder, at du kan køre dine rapporter og procedurer mod den pre-stagede tabel og dermed undgå de store 'joins'.
Man kan ikke altid anvende denne teknik, men er det muligt, kan man spare særdeles store mængder server-ressourcer.
Ved at pre-stage alle data kan man nøjes med at sammenkøre én gang, og det er godt, for i de fleste miljøer findes der populære tabeller, der sammenkøres hele tiden. Der er ingen grund til, at disse ikke kan blive pre-staged.
7: Slet og opdater i data-bundter
Her er en anden teknik, der ofte bliver helt overset. Det kan være et mareridt at opdatere eller slette store mængder data fra store tabeller, hvis ikke man gør det helt rigtigt.
Problemet er, at både sletning og opdatering kører som en solo-transaktion. Skal de afbrydes, eller sker der noget med systemet, mens de arbejder, skal hele systemet rulle hele transaktionen tilbage. Det kan tage meget lang tid.
Disse handlinger kan også blokere andre transaktioner og lave en flaskehals.
Løsningen er at slette eller opdatere i mindre bundter. Det vil løse problemet på flere måder.
Du behøver ikke skynde dig
For det første: Hvis transaktionen afbrydes, skal kun en mindre mængde opgaver rulles tilbage, hvilket betyder, at databasen kan komme online ige meget hurtigere.
For det andet: Mens de mindre sletninger/opdateringer committes til disken, kan andre snige sig ind og få udført databaseoperationer, så samtidigheden bliver øget betragteligt.
Samtidig har mange udviklere en idé om, at sletnings- og opdaterings-handlinger skal afsluttes samme dag, som de iværksættes.
Dette er imidlertid ikke altid sandheden - især ikke, hvis du arbejder med arkivering. Dette kan man strække ud så længe, man har lyst til.
