Die Lösung des gordischen Knotens: T-SQL objektorientiert UND schnell

Pro­gram­mie­rern aus der Welt der objekt­ori­en­tier­ten oder pro­ze­du­ra­len Spra­chen dürfte es beim Blick in so man­che Micro­soft-SQL-Daten­bank die Haare zu Berge ste­hen las­sen. Die glei­che Pro­gramm­lo­gik wird häu­fig immer und immer wie­der geschrie­ben und dies an ver­schie­dens­ten Stel­len in der Daten­bank. Das ist umso erstaun­li­cher, weil es bereits seit der SQL-Ser­ver-Ver­sion 2005 soge­nannte benut­zer­de­fi­nierte Funk­tio­nen gibt, die genau dies ver­hin­dern sol­len. Warum also wer­den diese nicht ver­wen­det? Die Ursa­che ist ihre teil­weise kata­stro­phale Per­for­mance. Nutzt man diese Skalar­wert­funk­tio­nen zur Zen­tra­li­sie­rung des Quell­codes muss man wohl oder übel ein schlech­tes Lauf­zeit­ver­hal­ten in Kauf neh­men. Von daher hat man die Wahl zwi­schen Pest oder Cho­lera – sau­bere Archi­tek­tur oder gute Per­for­mance.
Zum Glück ist aber auch die Daten­bank­welt nicht ganz so schlecht wie es auf den ers­ten Blick scheint. Mit ein paar weni­gen Hand­grif­fen kann man tat­säch­lich den Quell­code zen­tra­li­sie­ren und das bei sehr gutem Lauf­zeit­ver­hal­ten. Wie das geht? Ein­fach wei­ter­le­sen… wei­ter­le­sen…

SUM-Where OVER the rainbow

Bereits 2007 haben wir uns in unse­rem Blog Gedan­ken gemacht, wie lange OLAP-Daten­ban­ken wohl noch über­le­ben wer­den. Im Zeit­al­ter des Delta­Master Import­Wiz­zard kommt man auch tat­säch­lich ab und an ins Grü­beln, wozu man diese Form der Daten­ban­ken über­haupt noch benö­tigt? Bei genauer Betrach­tung fin­det man aber schnell zahl­rei­che Gründe, warum wir immer noch lie­ber Wür­fel als Tabel­len bauen. Neben dem deut­lich schnel­le­ren Aggre­ga­ti­ons­ver­hal­ten einer mul­ti­di­men­sio­na­len Daten­bank zählt auch die MDX-Zeit­in­tel­li­genz nach wie vor zu den Plus­punk­ten. Rela­tio­nal Kumu­lie­ren bei­spiels­weise erzeugt bei einem T-SQL-Pro­gram­mie­rer nach wie vor ein flaues Gefühl in der Magen­ge­gend.
2012 ist jetzt auch Micro­soft auf die Idee gekom­men und sagt ihrer eige­nen OLAP-Daten­bank den Kampf an. Mit dem neuen Tabu­lar Mode“ und der Abfra­ge­spra­che DAX des SQL Ser­vers 2012 gibt Micro­soft ein deut­li­ches State­ment für rela­tio­nale Daten­ban­ken ab. Im Zuge des­sen wur­den auch Imple­men­tie­rungs­lü­cken bereits exis­tie­ren­der T-SQL-Befehle beho­ben, so dass künf­tig eine rela­tio­nale Kumu­la­tion einem Pro­gram­mie­rer nur noch ein müdes Lächeln ins Gesicht zau­bern wird.
Wenn Sie wis­sen wol­len wie, dann fol­gen Sie mir ein­fach auf dem Weg zum Ende des Regen­bo­gens… wei­ter­le­sen…

Immer diese Stammdaten, Teil 2

Will­kom­men zu dem zwei­ten Teil mei­nes Bei­trags über Ände­run­gen von Stamm­da­ten. Wie ich bereits im ers­ten Teil ange­kün­digt habe, werde ich mich heute der Erwei­te­rung der bis­her bereits erstell­ten Trans­for­ma­tion wid­men. Zunächst ein klei­ner Rück­blick, was haben wir schon gemacht.
In Teil I haben wir im BI-Deve­lop­ment Stu­dio (kurz: BIDS) ein Paket mit einem inte­grier­ten Loo­kup-Task (deut­sch: Suche) erstellt. Der Task ver­glich die Quell­da­ten bereits mit den vor­han­de­nen Daten­sät­zen in der Ziel­ta­belle auf unse­rem SQL-Ser­ver und mit Hilfe eines klei­nen Scripts am Ende des Daten­flus­ses konn­ten wir neue Daten­sätze in die Tabelle mit auf­neh­men. Dar­über hin­aus hat­ten wir den Loo­kup-Task bereits so kon­fi­gu­riert, dass die Spal­ten Posi­tion“ und Gewicht“ bereits in einer Art Über­wa­chung“ (im BIDS spre­chen wir hier von der Aus­gabe für Such­über­ein­stim­mun­gen) vor­ge­hal­ten wur­den. Zusätz­lich hat das SQL-Script dann noch in die Ziel­ta­belle das Import­da­tum ein­ge­tra­gen bzw. aktua­li­siert. Das war schon sehr schön, aber wir wol­len noch mehr, oder?
Typi­sche Fra­gen wie: Wann wurde der Wert denn geän­dert?“ oder meist noch wich­ti­ger Was hat sich geän­dert?“ kön­nen wir unse­ren Kun­den so lei­der noch nicht beant­wor­ten. Mit nur ein paar klei­nen Ände­run­gen an unse­rem Import­pro­zess brin­gen wir auch hier Licht ins Dun­kel. Und wie genau? Ein­fach wei­ter­le­sen und mit­ma­chen, es lohnt sich. wei­ter­le­sen…

Einsatz von Merge bei Historisierung von Attributen (Teil 2)

In mei­nem letz­ten Bei­trag lern­ten wir wie die Inhalte zweier Tabel­len, mit Hilfe von MERGE”, syn­chro­ni­siert wer­den kön­nen. Heute schauen wir uns an, wie MERGE” uns bezüg­lich His­to­ri­sie­rung der Daten behilf­lich sein kann.
Sicher kön­nen Sie sich noch an die His­to­ri­sie­rung von Attri­bu­ten erin­nern? (Bei­trag vom Juni 2011: His­to­ri­sche Betrach­tung von Stamm­da­ten im Data Wareh­ouse).
Dort wurde zusätz­lich zu meh­re­ren Lösungs­an­sät­zen auch der opti­male Ansatz vor­ge­stellt, näm­lich das His­to­ri­sie­ren durch Zeit­be­trach­tung. Dabei kamen Update- und Ins­ert-State­ments zum Zuge.
Die Ansätze, um Ände­run­gen in Dimen­si­ons­ta­bel­len zeit­be­zo­gen zu erfas­sen und gege­be­nen­falls his­to­ri­sch zu doku­men­tie­ren, sind auch unter dem Begriff Slowly Chan­ging Dimen­si­ons” Typ 2 (deut­sch: sich lang­sam ver­än­dernde Dimen­sio­nen) bekannt.
Man kann mit dem MERGE-Befehl von SQL Ser­ver 2008 die Pflege einer Typ 2 Slowly Chan­ging Dimen­sion (SCD) in einem Data Wareh­ouse in nur einem Befehl erle­di­gen.
Schauen wir uns ein­mal alle mög­li­chen Fälle bei einem Slowly Chan­ging Dimen­si­ons” (SCD2) an. wei­ter­le­sen…

NOT IN = NOT EXPECTED

Da pro­gram­miert man schon Jahr­zehnte lang T-SQL und erlebt doch noch Über­ra­schun­gen bei ver­meint­lich ein­fa­chen Befeh­len. Jüngst haben wir in einer Kun­den­um­ge­bung ver­schie­dene Opti­mie­run­gen durch­ge­führt und unter ande­rem NOT IN Befehle durch LEFT JOINs aus­ge­tauscht. Erwar­tet haben wir ein iden­ti­sches Abfra­ge­er­geb­nis bei deut­lich bes­se­rer Per­for­mance. Aber weit gefehlt. Aus einem uns zu dem Zeit­punkt noch nicht bekann­ten Grund lie­ferte die linke Ver­bin­dung“ ein voll­kom­men ande­res Ergeb­nis als das zuvor ver­wen­dete IN-Kom­mando. Nach einer lang­wie­ri­gen Suche, mit wie­der­hol­ten Zwei­feln an der eige­nen Fach­kom­pe­tenz, haben wir den Grund schließ­lich gefun­den. Und wie sich her­aus­ge­stellt hat, ist die­ser selbst für viele alte Hasen“ über­ra­schend. Also las­sen auch Sie sich über­ra­schen und nicht trau­rig sein – Sie sind in bes­ter Gesell­schaft… ;o) wei­ter­le­sen…