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ürf­te es beim Bli­ck in so man­che Micro­soft-SQL-Daten­bank die Haa­re zu Ber­ge 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­si­on 2005 soge­nann­te benut­zer­de­fi­nier­te Funk­tio­nen gibt, die gen­au dies ver­hin­dern sol­len. War­um also wer­den die­se nicht ver­wen­det? Die Ursa­che ist ihre teil­wei­se kata­stro­pha­le Per­for­man­ce. Nutzt man die­se 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­le­ra – sau­be­re Archi­tek­tur oder gute Per­for­man­ce.
Zum Glück ist aber auch die Daten­bank­welt nicht ganz so schlecht wie es auf den ers­ten Bli­ck scheint. Mit ein paar weni­gen Hand­grif­fen kann man tat­säch­li­ch 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 lan­ge 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­li­ch ab und an ins Grü­beln, wozu man die­se Form der Daten­ban­ken über­haupt noch benö­tigt? Bei genau­er Betrach­tung fin­det man aber schnell zahl­rei­che Grün­de, war­um wir immer noch lie­ber Wür­fel als Tabel­len bau­en. Neben dem deut­li­ch 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­wei­se erzeugt bei einem T-SQL-Pro­gram­mie­rer nach wie vor ein flau­es 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 neu­en 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­na­le Daten­ban­ken ab. Im Zuge des­sen wur­den auch Imple­men­tie­rungs­lü­cken bereits exis­tie­ren­der T-SQL-Befeh­le beho­ben, so dass künf­tig eine rela­tio­na­le Kumu­la­ti­on 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, wer­de ich mich heu­te der Erwei­te­rung der bis­her bereits erstell­ten Trans­for­ma­ti­on wid­men. Zunächst ein klei­ner Rück­bli­ck, 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­gli­ch die Quell­da­ten bereits mit den vor­han­de­nen Daten­sät­zen in der Ziel­ta­bel­le auf unse­rem SQL-Ser­ver und mit Hil­fe eines klei­nen Scripts am Ende des Daten­flus­ses konn­ten wir neue Daten­sät­ze in die Tabel­le 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­ti­on“ und Gewicht“ bereits in einer Art Über­wa­chung“ (im BIDS spre­chen wir hier von der Aus­ga­be für Such­über­ein­stim­mun­gen) vor­ge­hal­ten wur­den. Zusätz­li­ch hat das SQL-Script dann noch in die Ziel­ta­bel­le 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 wur­de 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 gen­au? 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 Inhal­te zwei­er Tabel­len, mit Hil­fe von MERGE”, syn­chro­ni­siert wer­den kön­nen. Heu­te schau­en wir uns an, wie MERGE” uns bezüg­li­ch His­to­ri­sie­rung der Daten behilf­li­ch 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­ou­se).
Dort wur­de zusätz­li­ch zu meh­re­ren Lösungs­an­sät­zen auch der opti­ma­le Ansatz vor­ge­stellt, näm­li­ch das His­to­ri­sie­ren durch Zeit­be­trach­tung. Dabei kamen Update- und Ins­ert-State­ments zum Zuge.
Die Ansät­ze, 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 Slow­ly Chan­ging Dimen­si­ons” Typ 2 (deut­sch: sich lang­sam ver­än­dern­de Dimen­sio­nen) bekannt.
Man kann mit dem MER­GE-Befehl von SQL Ser­ver 2008 die Pfle­ge einer Typ 2 Slow­ly Chan­ging Dimen­si­on (SCD) in einem Data Wareh­ou­se in nur einem Befehl erle­di­gen.
Schau­en wir uns ein­mal alle mög­li­chen Fäl­le bei einem Slow­ly Chan­ging Dimen­si­ons” (SCD2) an. wei­ter­le­sen…

NOT IN = NOT EXPECTED

Da pro­gram­miert man schon Jahr­zehn­te lang T-SQL und erlebt doch noch Über­ra­schun­gen bei ver­meint­li­ch ein­fa­chen Befeh­len. Jüngst haben wir in einer Kun­den­um­ge­bung ver­schie­de­ne Opti­mie­run­gen durch­ge­führt und unter ande­rem NOT IN Befeh­le durch LEFT JOINs aus­ge­tauscht. Erwar­tet haben wir ein iden­ti­sches Abfra­ge­er­geb­nis bei deut­li­ch bes­se­rer Per­for­man­ce. Aber weit gefehlt. Aus einem uns zu dem Zeit­punkt noch nicht bekann­ten Grund lie­fer­te die lin­ke Ver­bin­dung“ ein voll­kom­men ande­res Ergeb­nis als das zuvor ver­wen­de­te IN-Kom­man­do. 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ß­li­ch gefun­den. Und wie sich her­aus­ge­stellt hat, ist die­ser selbst für vie­le 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…