Hier ist Bastelei notwendig. Zumindest in Net ist das Databinding besser gelöst.
naja, Databinding Verfahren welcher Art auch immer sind auch nicht immer das gelbe vom Ei, ich kenn da diverse Kundenprojekte aus der Praxis, bei denen man sich darauf verlassen hat, das die Zugriffsschicht das schon gut und performant macht, ob das nun in .NET auf Basis Linq ist oder diverse Java App Server sind, oder auch Delphi
Midas. Was der eine als Vorteil sieht, nämlich kein
SQL schreiben zu müssen, resultiert aber meist darin, das am Ende trotzdem
SQL an den Server geschickt wird. Es gab mal vor Jahren eine Anfrage hier in der
DP, wo als Resultat ein
SQL mit verschachtelten In Operator mit ca 2000 Werten erzeugt wurde.
Wenn deine Middleware nun Daten von 1000 Records braucht und diese wie leider sehr oft auf 1000 unterschiedliche SQLs verteilt, dann brauchst du dir über Performance keine Gedanken machen. Damit hast du als Programmierer oder auch Softwareentwickler das Leben zwar eine gewisse Zeit einfacher, wenn dann aber Datenmengen größer werden und die Anzahl Benutzer größer wird, dann stehst du in einer Sackgasse.
Nur weil MS da diverse speicherbasierende Optimierungen in den
SQL Server gepackt hat ist das auch mit vergleichbar großen Datenmenge mit Linq zum Beispiel benutzbar, aber es gibt diverse Projekte, da fallen die Microsoft Produkte durch deren Lizenzkosten schon mal weg (das betrifft selten kleine Firmen, meist sind das auch Enterprise Unternehmen).
Wir haben gerade so einen Fall, bei dem ein Zeitarbeitsunternehmen für 4000 User die Arbeitszeitmeldungen via Weboberfläche in das Zielsystem Navision zurückschreiben muss. Laut Microsoft heißt das relativ einfach, das man 4000 named Client Lizenzen braucht, kann man sich ja vorstellen was das kostet. Nun gut, ist mit Firebird, Apache, PHP und IBExpert realisiert, läuft ohne Lizenzkosten und eine Job in Navision holt sich die Daten von Firebird. Spart eine Unmenge an Geld und ist extrem flexibel. Aber das gehört eigentlich gar nicht zum Thema....
Ich kenne diverse Kunden, die
Midas verfluchen, aber durch jahrelange Programmierung doch sehr damit verheiratet sind. Wenn ich bei denen im Monitoring auf dem
FB Server nachschau, was die Applikationen für SQLs ablaufen lassen, dann kann mir kaum jemand sagen, wo im Quellcode genau dieser Teil hinterlegt ist. So einfache Klassiker wie die Property Recordcount, die die Anzahl der Records ermittelt, in dem die einfach auf den Client heruntergeladen werden und dort gezählt werden, lass ich mal außen vor, das findet man schon leicht mal. Auch RequestLive Queries auf TDataset Basis machen nicht immer das was man so denkt, aber je nach Bibliothek kann man das recht gut eingreifen, z.B. IBDAC.
Wenn du aber wie ich für einen Kunden mit dem Magenta T vor der Haustür mal einen Kabel/Fasern Kopierprozess auf Basis eines Appservers optimieren sollst, bei dem Kabel mit Fasern von einem Standort zu einem anderen verschoben werden sollen (1 Kabel mit 72 Fasern, d.h. 73 Datensätze müssen angefasst werden), der Appserver auf dem Weg dahin aber ca 1500 Transaktionen mit weit über 100000 SQLs veranstaltet, und je nach Lust und Laune zwischen 30 und 50 Fasern verschiebt, aber leider nie 72, weil irgendeine der Transaktionen auf einen Deadlock lief, dann ist der Begriff optimieren da einfach fehl am Platze. Ich hatte als Lösung dafür gerne mal fdisk vorgeschlagen, Platte löschen und neu anfangen, geht aber auch nicht immer. Das ist ein krasses Beispiel, aber leider Realität. Und dummerweise glauben viele, das man dadurch das man die Abstraktionsschicht dazwischen packt, erhebliche Vorteile hat. Kurzfristig mag das sein, aber ganz oft geht das tierisch in die Hose, wenn es denn nachher ans Eingemachte geht und man mit diversen Gigabyte an Daten zu tun hat.
Die Nutzung der Standardkomponenten in Delphi sollte man auch da lassen wo die sind, ohne eigene Architektur muss man halt Kompromisse eingehen, aber die sind aus meiner Sicht für 90% der Delphi Anwender ok und dir restlichen 10% benötigen da eh eigene Lösungsansätze. Der Umstieg auf eine andere Plattform (z.B. .NET mit Linq) ersetzt da aber nur den Teufel durch den Belzebub.
Schöne Grüße
Holger
www.ibexpert.com