Jag har 5 olika sql-frågor som är snarlika men det finns ändå ett par skillnader, inte bara på ett ställe utan på flera. Det är inga komplicerade frågor men ganska långa med många tabeller inblandade. Skillnaderna handlar om olika sorteringsordning, where-satserna är olika, någon använder "top" osv... alltså lite smått och gott alltså.
Jag skulle gärna vilja slå ihop dessa frågor till en men vet inte riktigt hur eller ens om jag bör göra det. Det enda sättet jag ser är att med hjälp av inskickade parametrar styra frågan åt olika håll med if-satser, case och liknande. Alternativt att man skippar sp:s och bygger upp frågan löpande i koden istället. Eller ska man behålla frågorna som de är? De uppdateras inte så ofta men det kan tänkas att det blir förändringar ibland och det är förstås inte optimalt att behöva göra samma förändring på fem olika ställen... Hur ska man tänka? Prestandan är viktig i de här frågorna.
Så länge det inte är extremt mycket data så har jag svårt att se att du kommer få en märkbar prestandaförlust av att slå ihop frågorna till en.
Ur underhållssynpunkt kan det ju vara fördelaktigt att ha de ihopslagna under förutsättningen att du även slår ihop så mycket kod i proceduren som möjligt.
Ja, det vore smidigt om jag kunde få ihop dem. Et exempel, en order by skiljer sig mellan de olika frågorna... ORDER BY Tabell.(X, Y eller Z). Hur löser man på bästa sätt de olika sorteringsordningarna mha en variabel? Ska man ha en if? Läste i en annan fråga nyss att en sp inte kan "kompileras" när det finns logiska villkor i dem och att den därför förlorar en massa prestanda?
Ja, det vore smidigt om jag kunde få ihop dem. Et exempel, en order by skiljer sig mellan de olika frågorna... ORDER BY Tabell.(X, Y eller Z). Hur löser man på bästa sätt de olika sorteringsordningarna mha en variabel? Ska man ha en if? Läste i en annan fråga nyss att en sp inte kan "kompileras" när det finns logiska villkor i dem och att den därför förlorar en massa prestanda?
Som sagt, jag tror fortfarande du inte märker av någon prestandaförlust om det inte rör sig om väldigt många anrop till proceduren.
En IF lämpar sig inte i ditt fall eftersom du isåfall måste lägga ut hela SELECT-frågan per sortering. CASE är bättre.
ORDER BY
CASE WHEN @InputParameter = 1 THEN Kolumn1
WHEN @InputParameter = 2 THEN Kolumn2
ELSE Kolumn3
Känner du till VIEWS? Om inte så rekommenderar jag dessa eftersom dom finns till för just detta ändamål. Man skapar virituella tabeller som kan vara kombinationer av flera tabeller.
Skapa en VIEW av din SQL-fråga och sedan du ställa SELECT-frågor mot denna VIEW precis som en tabell, men med specifika WHERE- och ORDER BY-satser.
Känner du till VIEWS? Om inte så rekommenderar jag dessa eftersom dom finns till för just detta ändamål. Man skapar virituella tabeller som kan vara kombinationer av flera tabeller.
Skapa en VIEW av din SQL-fråga och sedan du ställa SELECT-frågor mot denna VIEW precis som en tabell, men med specifika WHERE- och ORDER BY-satser.
Klokt!
263 ms totalt · 4 externa anrop · v20260731065814-full.6fe65c25
