Moje první myšlenka je -- jaký je problém s výkonem? Ujistěte se, že máte smyčku (jednou na řádek pro použití kde) uvnitř smyčky, která spouští dotaz. Ale dostáváte špatné plány realizace? Jsou vaše sady výsledků obrovské? Ale vraťme se k obecnému. Jak jednou vyřeší tento problém? SQL ve skutečnosti neukládá zapamatování (jak zdůrazňuje slavný @Martin_Smith). Tak co má kluk dělat?
Možnost 1 – Nový design
Vytvořte zcela nový design. V tomto konkrétním případě @Aaron_Bertrand poukazuje na to, že kalendářová tabulka může vyhovovat vašim potřebám. Docela správný. V situacích mimo kalendář vám to moc nepomůže, ale jak už to v SQL bývá, musíte myslet trochu jinak.
Možnost 2 – Nazvat UDF méně
Zúží množinu položek, které tuto funkci volají. To mi hodně připomíná, jak udělat úspěšný stránkování / počítání řádků . Vygenerujte malou sadu výsledků, která má požadované odlišné hodnoty a potom zavolejte své UDF, takže bude voláno jen několikrát. To může nebo nemusí být možnost, ale může fungovat v mnoha scénářích.
Možnost 3 – Dynamický UDF
Pravděpodobně mě za tento návrh vykážou z místnosti, ale jde to. Co dělá tento UDF pomalým, je příkaz select uvnitř smyčky. Pokud se váš sváteční stůl opravdu mění jen zřídka, můžete na stůl položit spoušť. Spouštěč by zapsal a aktualizoval UDF. Nové UDF by mohly brutálně vynutit všechna svá rozhodnutí. Bylo by to trochu jako kanibalismus s SQL píšícím SQL? Tak určitě. Ale zbavilo by se poddotazu a zrychlilo UDF. Nechte hekání začít.
Možnost 4 – zapamatujte si to!
Zatímco SQL neumí přímo memoovat, máme SQL CLR. Převeďte UDF na SQL CLR udf. V CLR můžete používat statické proměnné. Můžete snadno uchopit stůl Holidays v nějakém pravidelném intervalu a uložit je do hashtable. Pak už jen přepište svou smyčku v CLR. Můžete dokonce jít dále a celou odpověď si zapamatovat, pokud je to vhodná logika.
Aktualizace:
Možnost 1 - Opravdu jsem se zde snažil zaměřit na obecné, nikoli na příklad funkce, kterou jste použili výše. Současný design vašeho UDF však umožňuje více hovorů ke svátečnímu stolu, pokud se vám stane, že jich zasáhnete několik v řadě. Použití jakési tabulky ve stylu kalendáře, která obsahuje seznam „špatných dnů“ a odpovídající „další pracovní den“, vám umožní odstranit potenciál pro vícenásobné shody a dotazy.
Možnost 3 – Zatímco doména není předem známa, můžete velmi dobře upravit svůj sváteční stůl. Pro daný den dovolené by obsahoval následující odpovídající pracovní den. Z těchto údajů byste mohli vyplivnout UDF s dlouhým případem (když '5/5/2012' pak '5/14/2012' nebo něco podobného) na dně. Tato strategie nemusí fungovat pro každý typ problému, ale mohla by fungovat dobře pro některé typy problémů.
Možnost 4 – Každá technologie má své důsledky. Je třeba nasadit CLR, upravit konfiguraci serveru SQL a SQL CLR je omezeno na framework 3.5. Osobně jsem tyto úpravy považoval za dostatečně snadné, ale vaše situace může být jiná (řekněme neposlušný DBA nebo omezení úprav produkčních serverů).
Použití statických proměnných vyžaduje, aby sestavení byla udělena PLNÁ DŮVĚRA . Budete se muset ujistit, že jste správně zamykali.
Existují nějaké důkazy že na velmi vysoké úrovně transakcí CLR nefunguje tak dobře jako přímé SQL. Ve vašem scénáři však toto pozorování nemusí být použitelné, protože neexistuje přímá korelace SQL pro to, co se snažíte udělat (zapamatovat).