Pähkinä #13 menee VAR,Return, Calculate laskentakontekstien juurelle. Kysymys kuuluu, Mikä luku palautuu kohtaan:
Class=H
Color=Black
Year=2005
Näet näytöllä luvut, kuten ne ovat silloin kun käytetään suuretta SUM(‘FactInternetSales'[SalesAmount]),
Jos suure vaihdetaan seuraavaksi:
Sales2 =
VAR classvalues = values(‘DimProduct'[Class])
var sumvalue=CALCULATE(SUM(‘FactInternetSales'[SalesAmount]))
RETURN
CALCULATE(SUM(‘FactInternetSales'[SalesAmount])-sumvalue,ALLEXCEPT(‘DimProduct’,DimProduct[Class]),ALL(‘DimDate’))
Mitä tulee ko. kohtaan?
Class=H
Color=Black
Year=2005
Malli on tarvittavilta osin tässä:
Palauta suureen summa forms-lomakkeella.
Pähkinän #12 ratkaisu
Pähkinässä #12 ihmeteltiin uutta adaptiivista join-operaattoria SQL Serverissä. Ko. operaattori avasi portit dynaamiselle suoritussuunnitelmalle! Aikaisemmin SQL Server päätti tehdä jotain etukäteen ja sitten itsepäisesti suoritti ko. operaattoria vaikka arvaus olisi mennyt metsään.
Nyt tämä uusi operaattori mahdollistaa kyselylle suoritussuunnitelman tallentamisen ja sitten annettujen parametrien perusteella se voi tilastoista päätellä kumpaa haaraa se alkaisi suorittamaan. Ja sitten jos suorituksen aikana arvaus menee pieleen, se voi vielä vaihtaa operaattoria lennosta. Tämä operaattorin vaihtaminen on harvinainen, mutta tilanteessa missä adaptiivinen join on tehnyt HASH-match vs. NestedLoop parin ja lähtee liikkeelle nestedloopilla, voi operaattori vaihtaa scaniin jos looppi palauttaakin ihan liikaa rivejä arvaukseen nähden. Tämä sen takia, että loopissa joka iteroinnilla saadaan vain yksi arvo ja jos työmäärä arvon saamiseksi on yhtään isompi, voi scan olla itseasiassa paljon nopeampi tapa.
Vastauksia tuli 3, kaikki olivat vähän eri sanamuotoja mutta just oikein! Huhupuheita on ollut että adaptiivisuus tulee myös muutamaan muuhun operaattoriin, kuten sort-group tai hash-group tyyppisiin rakenteisiin, toivottavasti nähdään!