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

Programmierern aus der Welt der objektorientierten oder prozeduralen Sprachen dürfte es beim Blick in so manche Microsoft-SQL-Datenbank die Haare zu Berge stehen lassen. Die gleiche Programmlogik wird häufig immer und immer wieder geschrieben und dies an verschiedensten Stellen in der Datenbank. Das ist umso erstaunlicher, weil es bereits seit der SQL-Server-Version 2005 sogenannte benutzerdefinierte Funktionen gibt, die genau dies verhindern sollen. Warum also werden diese nicht verwendet? Die Ursache ist ihre teilweise katastrophale Performance. Nutzt man diese Skalarwertfunktionen zur Zentralisierung des Quellcodes muss man wohl oder übel ein schlechtes Laufzeitverhalten in Kauf nehmen. Von daher hat man die Wahl zwischen Pest oder Cholera – saubere Architektur oder gute Performance.
Zum Glück ist aber auch die Datenbankwelt nicht ganz so schlecht wie es auf den ersten Blick scheint. Mit ein paar wenigen Handgriffen kann man tatsächlich den Quellcode zentralisieren und das bei sehr gutem Laufzeitverhalten. Wie das geht? Einfach weiterlesen… weiterlesen…

SUM-Where OVER the rainbow

Bereits 2007 haben wir uns in unserem Blog Gedanken gemacht, wie lange OLAP-Datenbanken wohl noch überleben werden. Im Zeitalter des DeltaMaster ImportWizzard kommt man auch tatsächlich ab und an ins Grübeln, wozu man diese Form der Datenbanken überhaupt noch benötigt? Bei genauer Betrachtung findet man aber schnell zahlreiche Gründe, warum wir immer noch lieber Würfel als Tabellen bauen. Neben dem deutlich schnelleren Aggregationsverhalten einer multidimensionalen Datenbank zählt auch die MDX-Zeitintelligenz nach wie vor zu den Pluspunkten. Relational Kumulieren beispielsweise erzeugt bei einem T-SQL-Programmierer nach wie vor ein flaues Gefühl in der Magengegend.
2012 ist jetzt auch Microsoft auf die Idee gekommen und sagt ihrer eigenen OLAP-Datenbank den Kampf an. Mit dem neuen „Tabular Mode“ und der Abfragesprache DAX des SQL Servers 2012 gibt Microsoft ein deutliches Statement für relationale Datenbanken ab. Im Zuge dessen wurden auch Implementierungslücken bereits existierender T-SQL-Befehle behoben, so dass künftig eine relationale Kumulation einem Programmierer nur noch ein müdes Lächeln ins Gesicht zaubern wird.
Wenn Sie wissen wollen wie, dann folgen Sie mir einfach auf dem Weg zum Ende des Regenbogens… weiterlesen…

Immer diese Stammdaten, Teil 2

Willkommen zu dem zweiten Teil meines Beitrags über Änderungen von Stammdaten. Wie ich bereits im ersten Teil angekündigt habe, werde ich mich heute der Erweiterung der bisher bereits erstellten Transformation widmen. Zunächst ein kleiner Rückblick, was haben wir schon gemacht.
In Teil I haben wir im BI-Development Studio (kurz: BIDS) ein Paket mit einem integrierten Lookup-Task (deutsch: Suche) erstellt. Der Task verglich die Quelldaten bereits mit den vorhandenen Datensätzen in der Zieltabelle auf unserem SQL-Server und mit Hilfe eines kleinen Scripts am Ende des Datenflusses konnten wir neue Datensätze in die Tabelle mit aufnehmen. Darüber hinaus hatten wir den Lookup-Task bereits so konfiguriert, dass die Spalten „Position“ und „Gewicht“ bereits in einer Art „Überwachung“ (im BIDS sprechen wir hier von der Ausgabe für Suchübereinstimmungen) vorgehalten wurden. Zusätzlich hat das SQL-Script dann noch in die Zieltabelle das Importdatum eingetragen bzw. aktualisiert. Das war schon sehr schön, aber wir wollen noch mehr, oder?
Typische Fragen wie: „Wann wurde der Wert denn geändert?“ oder meist noch wichtiger „Was hat sich geändert?“ können wir unseren Kunden so leider noch nicht beantworten. Mit nur ein paar kleinen Änderungen an unserem Importprozess bringen wir auch hier Licht ins Dunkel. Und wie genau? Einfach weiterlesen und mitmachen, es lohnt sich. weiterlesen…

Einsatz von Merge bei Historisierung von Attributen (Teil 2)

In meinem letzten Beitrag lernten wir wie die Inhalte zweier Tabellen, mit Hilfe von “MERGE”, synchronisiert werden können. Heute schauen wir uns an, wie “MERGE” uns bezüglich Historisierung der Daten behilflich sein kann.
Sicher können Sie sich noch an die Historisierung von Attributen erinnern? (Beitrag vom Juni 2011: Historische Betrachtung von Stammdaten im Data Warehouse).
Dort wurde zusätzlich zu mehreren Lösungsansätzen auch der optimale Ansatz vorgestellt, nämlich das Historisieren durch Zeitbetrachtung. Dabei kamen Update- und Insert-Statements zum Zuge.
Die Ansätze, um Änderungen in Dimensionstabellen zeitbezogen zu erfassen und gegebenenfalls historisch zu dokumentieren, sind auch unter dem Begriff “Slowly Changing Dimensions” Typ 2 (deutsch: sich langsam verändernde Dimensionen) bekannt.
Man kann mit dem MERGE-Befehl von SQL Server 2008 die Pflege einer Typ 2 Slowly Changing Dimension (SCD) in einem Data Warehouse in nur einem Befehl erledigen.
Schauen wir uns einmal alle möglichen Fälle bei einem “Slowly Changing Dimensions” (SCD2) an. weiterlesen…

NOT IN = NOT EXPECTED

Da programmiert man schon Jahrzehnte lang T-SQL und erlebt doch noch Überraschungen bei vermeintlich einfachen Befehlen. Jüngst haben wir in einer Kundenumgebung verschiedene Optimierungen durchgeführt und unter anderem NOT IN Befehle durch LEFT JOINs ausgetauscht. Erwartet haben wir ein identisches Abfrageergebnis bei deutlich besserer Performance. Aber weit gefehlt. Aus einem uns zu dem Zeitpunkt noch nicht bekannten Grund lieferte die „linke Verbindung“ ein vollkommen anderes Ergebnis als das zuvor verwendete IN-Kommando. Nach einer langwierigen Suche, mit wiederholten Zweifeln an der eigenen Fachkompetenz, haben wir den Grund schließlich gefunden. Und wie sich herausgestellt hat, ist dieser selbst für viele „alte Hasen“ überraschend. Also lassen auch Sie sich überraschen und nicht traurig sein – Sie sind in bester Gesellschaft… ;o) weiterlesen…