Nosql och Hadoop i all ära, men de flesta databasfrågor ställs med all säkerhet fortfarande mot relationsdatabaser. Det betyder allt som oftast att någon får lov att skriva sql-satser för att få tag på data.

Men det är en kompetens som blir allt mindre attraktiv att skaffa sig för nya utvecklare. Och även om det är enkelt att komma i gång med att skriva sql-satser för att hämta data så tar det tid att lära sig knepen som ger bästa möjliga prestanda. Och bra prestanda kan man aldrig få nog av.

Läs också: Smart lösning för att hitta personer gav SM-guld i Sql Server

Om man dessutom väger in aspekter som att hantera så många samtidiga databasanvändare som möjligt på ett bra sätt så blir det ännu krångligare. Man behöver minimera låsningar av data, in- och utmatning och nätverkstrafik, förutom att själva databasfrågorna behöver optimeras.

Här ger IDG News nio handfasta tips för bättre prestanda.

1. Undvik pekare till varje pris

Det här borde vara självklart, men kanske är svårt att hålla i minnet (ursäkta skämtet). Pekare (cursors) kan inte bara ge dåliga prestanda, de kan också innebära att olika frågor blockerar varandra mer än nödvändigt, vilket ger sämre förutsättningar för många samtidiga databasanvändare.

2. Använd temporärtabeller...

Om du måste använda pekare, gör det på temporärtabeller. Det går snabbare och innebär kortare låsningstider.

3. ...så ofta du kan

Det finns gott om exempel på nyttan med temporärtabeller. Ett exempel är om du ska göra en join med en stor tabell och det inbegriper villkor för data i den stora tabellen. Fyll en temporärtabell med de data som ska väljas ut och gör en join med den tabellen. Det minskar processorkraften som krävs. Om du dessutom ska formulera flera frågor som inbegriper det urvalet så är det redan gjort, till exempel för flera rapporter eller procedurer.

4. Undvik nästlade vyer

Vyer (views) är bra för att dölja stora databasfrågor för användare. Men när man börjar nästla vyer inuti varandra kan prestanda bli lidande, eftersom stora mängder data behöver returneras varje gång en vy används. I värsta fall ger databasen upp. Så undvik nästlade vyer.

5. Använd Case i stället för Update

Tänk dig att du lagrar data i en temporärtabell och behöver ange ett visst värde om ett annat värde existerar, till exempel ange ”Prioritera” i en kolumn för kunder som handlat för mer än 100 000 kronor. Ett sätt att göra det är att först lagra data i temporärtabellen och sedan köra en Update-sats. Men det innebär flera skrivningar till temporärtabellen.

Ett annat sätt att lösa problemet är att skriva en Case-sats i den första databasfrågan, vilket innebär att den önskade texten formuleras redan innan data skrivs i temporärtabellen, vilket kan ge stora prestandavinster.

6. Dela upp borttagningar och uppdateringar

Det kan vara jobbigt att ta bort och uppdatera data i stora tabeller. Problemet är att en sådan operation körs som en transaktion. Om den måste avbrytas blir alla ändringar och borttagningar som redan gjorts ogjorda. Om du delar upp sådana här operationer i flera delar så behöver du inte göra om lika mycket jobb.

7. Undvik objektmappning

Ramverk för att mappa objekt till relationsdatabaser, kallas ORM, genererar ibland väldigt dålig sql-kod, med stora prestandaproblem som följd. Försök att skriva egen kod, gärna i procedurer, som används i stället.

Läs också: Databasoffensiv från Microsoft – mutar in ny mark med Cosmos

8. Använd procedurer om du kan

Förutom att koden blir mer elegant så har procedurer (stored procedures) även andra fördelar. De innebär minskad trafik, är enklare att optimera och enklare att återanvända.

9. Undvik triggers

Triggers, procedurer som körs vid speciella händelser, kan vara smidiga, men också leda till problem. Ett problem är att en trigger utförs i den transaktion som gör att den körs. Följden kan bli att flera tabeller blir låsta. Försök att dela upp det som ska utföras i flera transaktioner.

Om du är sugen på ännu fler prestandatips kan du läsa här.