Jeg husker den glade sommer (husker dog ikke helt hvornår det var) hvor jeg lå i solen og prøvede at læse op til en SQL Server eksamen. Det lykkedes aldrig at komme forbi kapitlet om opbygningen af den fysiske filstruktur i databasen. Det hører jo med til en MS certificering, så den blev ikke til noget.

SQL Server er den database jeg har arbejdet mest med, men til mit seneste hobby webprojekt var det naturlige valg MySql. Pandasan var så flink at vise mig XAMPP som findes i en light udgave, hvilket var præcis det jeg skulle bruge til mit hygge project. Uden at skulle installere services kan man ha' MySql kørerende på sin lokale maskine på få minutter.

For et hobby website har MySql syntax en meget nyttig kommando LIMIT. Denne kommando alene har tidligere gjort at jeg har prøvet kræfter med MySql. Paging bliver et spørgsmål om man lige kan gange sidestørrelse med sidenummer og det bør være overkommelig matematik for en programør. MySql provideren til .Net findes på MySql's website og er dermed ikke en 3rd party komponent som det var for nogle år siden.

Det virker generelt som om der er sket en del med MySql siden jeg sidst så på det. Og man kan også spørge om Are Commercial Databases Worth It?. Star Wars sammenligninger giver altid letforståelige forklaringer. Jeg har ikke selv oplevet de store forbedringer i SQL Server for mine små projekter. Og t4rzsan har jo set lidt på Parametriserede queries vs. stored procedures, så den konto er også brugt selvom MySql har fået Stored Procedures for snart lang tid siden.

Betyder det så noget at Oracle har købt SUN og dermed også MySql? Jeg har i forbindelse med et kursus på ITU stødt på Oracle og det var ikke overbevist. Det virker unødigt komplekst for at sælge nogle konsulenttimer, hvilket jeg mener er at narre folk. Selvom der er andre firmaer som bygger deres forretning på denne model, er det jo ikke et argument for at gøre det selv.

Nok med brok, se at komme igang med MySql. XAMPP kan downloades som zip og køres næsten uden setup. Det er et værdigt alternativ til SQL Server (også Express).

Jeg har tidligere arbejdet i et firma hvor vi brugte mange soft-delete (eller som det hedder i salgsbrochuren - Fuldt revisionsspor), dvs. man sletter ikke i databasen, men markerer istedet rækken for slettet. I vores tilfælde blev slettetidspunktet markeret, så objektets tilstand kunne genskabes på forskellige valørdatoer. De første man lægger mærke til er naturligvis at databasen vokser hurtigt og at alle queries indeholder 'DeletionTime NOT NULL'. Det var praksis og påkrævet af revisorer.

Man kan mene mange ting om soft-delete og Frans Bouma mener at Soft-deletes are bad. Inden vi ser lidt nærmere på hans løsningsforslag, så lad mig give ham ret i at, hvis du ikke har revisorer på nakken, så bør du nok finde på en anden løsning end soft-deletes. Gammelt data er trods alt.. ja, gammelt. Jeg ved godt at vi lever i Google-tid og man bare kan søge igennem alt, men lader du Google indeksere dine business data?

Vi har allerede etableret et behov for at bevare data af juridiske grunde, men det er også værd at nævne at data forbliver slettet. Gammelt data bruges ikke til at "spole" objektets tilstand tilbage ved at "undelete" data, altså fjerne slettetidspunktet i databasen. Derimod oprettes en ny linie som en kopi af den gamle. Ellers ville vi miste det fulde revisionsspor. Vi er ikke i det Frans Bouma kalder tilfælde to (men beskriver først). Det er også noget rod.

En naturlig løsning er at arkivere gammelt data, som man arkiverer gamle emails (eller hvordan er det nu lige er man får håndteret dem?). Frans Bouma foreslår at bruge database triggers. En delete trigger kan kopiere det slettede data over i anden tabel. Et forslag som jeg ikke kan stå 100% bag. Jeg kan se ideen i at kopiere slettet data over
i en anden tabel. Det er alligevel oftest, at man kun skal bruge de aktuelle data og i de tilfælde hvor man skal se gammelt data vil det kunne klares med et view.

Det er database triggeren som giver mig problemer. Der er mange gode og dårlige grunde til at bruge triggers eller lade være, men min helt store anke i dette tilfælde er manglende triggers. Hvis man får slettet triggeren fra database så får man ingen fejlbeskeder. Uden at vide det kan man få slettet en masse data som burde være kopieret. Man opdager det først når man skal bruge de gamle data. En stored procedure ville kunne gøre det samme og man vil helt sikkert opdage hvis den manglede.

Jeg vil mene at soft-deletes har deres plads, specielt for enterprise data. Men derfor er det stadig tilladt at organisere sine data bedst muligt. Bare lov mig at du ikke bruger en delete trigger som er kritisk for dine data.

Et meget hyppigt anvendt argument for at bruge stored procedures frem for parametriserede queries på SQL Server er performance.  Argumentet er, at eksekveringsplanen for sprocs kan caches på serveren.  Det er korrekt, at sådan forholdt det sig på SQL Server 7 og måske også på 2000, men efter min bedste overbevisning er SQL Server nu i stand til på samme måde at lave caching for parametriserede queries.

Det er svært at finde dokumentation af dette (hvis du har links, så giv dem til mig!), så jeg besluttede at lave et lille forsøg: Jeg lavede en lille testtabel og prøvede at indsætte 100.000 rækker 50 gange med en sproc og med en parametriseret INSERT statement.

Konklusionen?

Jeg kunne ikke se nogen forskel.  Selvfølgelig svinger tiderne noget i forhold til, hvad serveren ellers laver, men man kan ikke se, at den ene metode er hurtigere end den anden.

Der kan selvfølgelig være mange andre argumenter for at sprocs - f.eks. security.  Det vil jeg ikke gå yderligere ind i her, for det plejer at kunne få folk helt op at køre.

Historien er en anden med dynamisk opbygget SQL.  Her kan SQL Server ikke cache.  Men dynamisk opbygget SQL er i forvejen bandlyst pånær i særlige tilfælde, da det øger risikoen for SQL injection.