Nested Views

Thu, 15 Dec 2005 11:48:38 GMT

Mir ist gerade aufgefallen, dass viele einen Trick zur Beschleunigung von Abfragen nicht kennen.

Wenn ich zum Beispiel alle Mitarbeiter der Firma Northwind haben will, die mehr als 60 Bestellungen haben, mache ich eine Unterabfrage:

SELECT *
FROM   dbo.Employees
WHERE EmployeeID IN
(
    SELECT   EmployeeID
    FROM     dbo.Orders
    GROUP BY EmployeeID
    HAVING   COUNT(OrderID) > 60
)

Diese Art der Abfrage ist jedoch langsamer, als wenn ich zu einem einfachen Kniff greife. Ich definiere eine Abfrage direkt im Query und binde sie mit INNER JOIN ein:

SELECT *
FROM   dbo.Employees
INNER JOIN
(
    SELECT   EmployeeID
    FROM     dbo.Orders
    GROUP BY EmployeeID
    HAVING   (COUNT(OrderID) > 60)
) OverSixtyOrders
ON Employees.EmployeeID = OverSixtyOrders.EmployeeID

So umgebaut, ist die Abfrage um einiges schneller. Bislang Eingesetzt und getestet habe ich das bei SQL Server 2000 und der Jet Engine (Access)

Glaubenskriege sind ja in Mode

Wed, 15 Dec 2004 10:45:47 GMT

Man stelle sich vor, man bekommt soviel Zeit wie man braucht von seinem Arbeitgeber, auch finanzielle Mittel für externe Berater stehen gegebenfalls bereit. Das alles, um die Frage zu klären, auf welcher Architektur eine geplante und (mittlerweile) sehr komplexe Anwendung aufbaut, die eine frühere 2 Tier Anwendung Datenbankanwendung beerbt. Natürlich bekommt man ein paar Rahmenbedinungen, zum Beispiel das man von der, ja arbeitenden, Datenbankbasierten Lösung hin zu einer Objektorientierten Lösung will, da man mit der bestehenden Lösung an typische Grenzen stösst. So sind Ergänzungen oder Detailsänderungen oft unnötig aufwändig. Natürlich gibt es noch mehr Rahmenbedinungen, welche die Anforderungen an eine Architektur recht genau definieren.

Alles in allem sollte man glücklich sein eine solche Aufgabe zu erhalten? Weit gefehlt. Erster Anlauf ist der Austausch mit dem mitverantwortlichen Kollegen. Schon hier stehen die Meinungen gegeneinander.

Der eine sieht die Lösung in den RAD (Rapid Application Development) Features von Visual Studio und würde am liebsten einfach mit Typed Datasets maskenzentriert arbeiten.

Der andere sieht die Lösung in einer stärkeren Betonung der Businessschicht, wo er Datenbankzugriffe direkt ausformulieren will.

Ich will hier nicht näher auf die Vor- und Nachteile eingehen, die beide Ansätze haben - schon gar nicht auf die in Bezug auf das konkrete Projekt. Der Punkt war, da es hier nur 2 Parteien gab und von den Individuen her keine Annäherung stattfand, gab es eine lähmende Patt-Situation. Langsam schleicht sich so der erste Frust ein. Die einzige Lösung bestand darin, eine bessere Lösung zu finden, die beide Seiten (und die Führung) überzeugen könnte. Also fragt man in einem grösserem Kreis herum. Man fängt an, Artikel über mögliche Architekturen zu lesen (z.B. hier). Und schnell steigt die Frustrierung - soviele Leute man fragt, soviele Antworten erhält man. Oft kann man an der Antwort sehr genau ablesen wer aus welcher Ecke kommt. Wer Hauptsächlich mit Microsoft .Net Lösungen erarbeitet hat, neigt zu weniger Objektorientierung(OO) und zu mehr Rapid Application Development mit Typed Datasets, umgekehrt sind viele Entwickler mit einem breitgefächerterem Backround der OO sehr zugeneigt. Das Spektrum reichte von Vertretern der reinen Datenbank, die alle Business Logic in Triggern und Stored Procedures sehen, bis hin zu Lösungen, welche die Datenbank komplett maskieren und abstrahieren (Persistent Framework), wie Gentle.Net. Die Sache wird jedoch so richtig Haarig, wenn man bemerkt wie die einzelnen Entwickler und Architekten jeweils Ihre Architektur behandeln. Sie ist oft genug das einzig Wahre, alles andere ist längst veraltet und wer das einsetzt denkt nicht nach und kann das vermutlich auch garnicht. Die vorbereiteten Artikel kennen meist nur verteilte Anwendung im sogenannten Enterprise-Umfeld (wir haben nach wie vor eine Desktopanwendung mit einer zentralen Datenbank) und konzentrieren sich grosspurig auf die Kommunikation der einzelnen Schichten. Welcher hausbauende Architekt konzentriert sich eigentlich auf den Mörtel statt auf den Aufbau des Hauses und die Einteilung der Räumlichkeiten?
Allerdings war in der Quersumme ein Tipp immer wieder herauszuhören - Codegeneratoren wie MyGeneration, OlyMars oder Codesmith einzusetzen. Obwohl sie natürlich beliebigen Code erzeugen können, kommt jeder dieser Generatoren seinerseits mit einem Architekturmodell für die unteren Schichten. In "dOOdads" von MyGeneration fanden unsere beiden Streithähne vom Anfang nun eigentlich eine Lösung, mit der beide Parteien leben konnten. Die Geschichte geht noch weiter - und der Frustlevel stieg bei dem ein oder anderen in gefährliche Höhen, unvermeidlich durch die Einbeziehung eines Consultants, doch genug davon. Letztlich hat sich gezeigt, es handelt sich um einen Religionskrieg der genauso geführt wird wie die frage nach dem besten Betriebssystem - und man kommt zu keiner Lösung.