För att köra SQL Server-databaser framgångsrikt måste du vara angelägen om frågedesign. Tyvärr tänker de flesta inte på designprocessen en sekund. Som ett resultat gör de enkla misstag som, även om de är lätta att undvika, får långtgående konsekvenser.
Till att börja med, med dåligt skrivna frågor kan du inte garantera användarna blixtsnabba hämtningstider. Dina servrar kommer också att plågas av problem från dag ett. Och i dagens digitala värld är dessa misstag du inte har råd att göra. Men hur undviker du att göra dessa misstag? Här är tips på hur du går tillväga.
1. Misslyckas med att granska din datamodell
Din datamodell avgör hur användare får åtkomst till data. Så tänk igenom din modell redan från början. Om du inte gör det kommer du att behöva hantera svårhanterliga frågor och komplicerad kod längre fram, och båda påverkar prestanda negativt. Ett enkelt sätt att ta reda på vilka frågor som behövs för att komma åt data är att skriva ut din datamodell.
Eller ännu bättre, låt ett datamodelleringsverktyg göra det åt dig. Ett utskrifts- eller modelleringsverktyg låter dig se vad du står inför. Du har därför bättre förutsättningar att förenkla koden, öka kodningstiden, öka noggrannheten och förbättra prestandan.
2. Att inte ta hänsyn till din teknik
Vilken teknik använder du? Är det markörlogik eller uppsättningsbaserad logik? Det finns inget enkelt svar på just denna fråga:allt beror på den prestanda som bäst passar dina behov. Ta uppsättningsbaserad logik, till exempel. Det är det självklara valet för databasåtkomst. Trots allt är en SQL Server designad för det. Men markörlogik kan i vissa fall överträffa baserad logik. Nyckeln är att inte använda en teknik när den andra skulle vara bättre.
3. Använder inte gamla kodningstekniker
När du använder beprövade kodningstekniker hamnar du sällan i problem. Även kodningsmetoder du lärt dig från SQL Server 2005 kan visa sig vara användbara idag. Försök att använda TRY…CATCH-felhanteringstekniken i din kodning. Resultaten kan överraska dig. Att använda Common Table Expressions för hierarkier eller databasmotorn Common Language Runtime (CLR) kan också göra dig förvånad.
Om du behöver hjälp med att fräscha upp gamla tekniker, gör en revidering och leta efter några artiklar online. Det finns massor där ute. Här och här är ett par SQL-exempel.
4. Att inte dra nytta av peer review
Innan du distribuerar dina frågeplaner bör du låta någon annan granska dem. Chansen är stor att andra kommer att se vad du har missat. Deras recensioner av dina index och frågeprestanda hjälper dig ofta att förbättra din kod ytterligare. De kan också lära sig ett och annat av dig under processen, och vice-versa.
5. Det gick inte att testa dina frågor
Utvecklare hatar att behöva testa kod. För det första är det rigoröst. Och för det andra matchar testmiljön (hårdvara och data) sällan den verkliga produktionsmiljön. Men testning är en nödvändig och oundviklig del av kodningen. Så testa din kod noggrant och försök att efterlikna den slutliga produktionsmiljön så nära som möjligt när det är möjligt. Kom ihåg att dina frågor kan fungera bra med några hundra poster, men inte mot miljoner i den slutliga miljön.
Slutsats
Frågor bestämmer hastigheten och prestandan för en SQL-databas. Så försök att undvika vanliga misstag som att inte granska din datamodell eller att inte överväga vilken teknik du ska använda. Andra misslyckas med att använda gamla kodningstekniker, utnyttjar inte mekanismer för peer review och misslyckas med att testa dina frågor.