Also ein Rutsch, das macht es wohl schneller, aber nicht besser und nicht "nachhaltig" - tolles Wort!
Hä? Wieso nicht? Was ist an 'nachhaltig' als Wort bemerkenswert?
Wieso ist 'schneller' (hier) nicht 'besser'?
Wenn man die Daten in einem `SELECT` abholen kann, um sie in ein Array zu packen (wenn man es braucht), was soll daran nicht nachhaltig sein?
Ein Rutsch ist natürlich schnell, sagt das Wort ja schon.
Ich habe aber bereits nachgefragt, wie das Array bzw. das Mengengerüst ist. Wenn er eines Tages 10T Subcomponenten hat, macht Rutsch wahrscheinlich irgendwo halt.
Bezüglich der Nachhaltigkeit bzw. dem 'Änderungsaufwand' (falls ich das für dich übersetzen darf): Die Daten werden an einer(!) Stelle in der
DB erzeugt (Stored Procedure) und an einer(!) Stelle in der Anwendung empfangen und umgeformt (aka ins Array geschrieben).
Natürlich, Du darfst hier alles, was die Forenregeln erlauben.
Um Dich vielleicht etwas zu beruhigen, was Du da schreibst hätte von mir sein können. Ich hab kein Problem mit SP. Es ist leider so, dass man auch hier häufig zu lesen bekommt, "ich mach das in einer SP, dann ist es schneller". Das stimmt halt so pauschal nicht. Eine SP die nichts anderes tut, als ein Selectstatement zu kapseln, bringt keinen nenneswerten Geschwindigkeitsvorteil. Erst unter gewissen Umständen, habe ich ja schon geschrieben.
Selbst wenn man die komplette
DB umschreibt, muss man für diesen Ansatz nur die Stored Procedure anpassen. Und selbst wenn man die Datenstruktur in der Anwendung komplett neu schreibt, muss man widerum nur eine Stelle anpassen (die SP).
Bin mal gespannt, was Du hier optimieren willst. (bin ja immer offen für Verbesserungen)
Abgesehen von der fehlenden Programmierbarkeit, kann ich das ganze Interfacing auch mit Views erreichen. An einer guten SP will ich nichts optimieren, weiß nicht, wo Du das gelesen hast.
Was spricht gegen die einzelne Abfrage der benötigten Daten und deren verbleib im Dataset- ohne Array?
Wenn Du die Daten im Dataset lässt (und die Daten direkt aus der
DB holst) machst Du deine Anwendung komplett(!) abhängig vom konkreten
DB-Design: Ein Horrorszenario in komplexen Anwendungen.
Weiterhin: Will man die Daten anzeigen, aggregieren, weiterleiten, weiterverarbeiten etc. sollte man das schnellstmöglich aus dem Dataset holen. Etwas langsameres als ein Dataset fällt mir jedenfalls auf Anhieb nicht ein. Will man die Daten dagegen eh nur in seiner zusammengeklicken Oberfläche anzeigen (Chart o.ä.) dann kann man das so machen, also auf das Array verzichten. Aber so programmiert man heute eigentlich nur noch im LOB-Bereich, bei dem man die kleinen Frickeltools raushauen muss. Dafür ist Delphi ja geeignet.
Ich aggregiere Daten in der Datenbank, verarbeiten tu ich sie erst Recht dort. Z.B. in Stored Procs
Selbst eine Weiterleitung mache ich gerne im Backend, also der
DB per Link.
Komplette Abhängigkeit von der
DB. Das klingt doch langsam etwas nach Sales BlaBla. Natürlich mache ich mich mit diesen und anderen Dingen abhängig von der Struktur. Deswegen gebe ich mir idR Mühe, eine performante und flexible Struktur zu schaffen.
Man kann das natürlich alles machen wie Du sagst, es muss nur am Ende jemand tun und bezahlen. In diesem Thread bswp. war jetzt nicht die Rede davon, die große, finale Anwendung zu schreiben. Ich hab schon 2 mal gefragt wo die Reise denn hingehen soll und mögliches Vorgehen skiziert.
Zitat:
Zur StoredProc:
Das kann man machen, bringt aber m.E. im Vergleich zu Select nur ...
Du hast das nicht verstanden:
- Eine SP abstrahiert den Zugriff auf die Datenbank (Nachhaltigkeit bei Änderungen in der DB)
- Eine SP verbirgt das konkrete DB-Design. Ich kann hier Daten aus unterschiedlichen Tabellen zusammensuchen, die sich so nicht verknüpfen (JOIN) lassen. (Drastische Vereinfachung und Verbergen eines schlechten DB-Designs).
- Eine SP kann die Geschwindigkeit drastisch erhöhen: Wir schreiben gerade Anwendungen für die dritte Welt, bei der man mit Netzwerken um die 256kBit (shared auf 600 Clients) auskommen muss. Aber auch in Gigabit-Netzen zahlt sich jede gespaarte Anfrage aus: Eine SP kann auch mehrere Resultsets liefern (eine Batchanweisung natürlich auch).
Dochdoch, ich verstehe das sehr gut. Die Tatsache, dass Du bei der möglichen Performancesteigerung "kann" schreibst, ist auch der einzige Haken an Deiner Liste. Habe ich ja oben schon erläutert. Ich muss nicht in die 3.Welt schauen, ich kann meine Anwendung auch per ISDN laufen lassen.
Eine SP ist nicht per se die beste Lösung. Eine schlechte clientseitige Implementierung wird nicht automatisch besser dadurch, dass ich auf die DBSeite wechsel. Das ist eigentlich alles, was ich sagen wollte. Erfahrungsgemäß lassen sich
DB Anwendungen stellenweise bis zum Faktor 100, 1000, 10000 oder sogar unendlich tunen. Das ist keine Zauberei, sondern im Gegenteil recht einfach, wenn sie nämlich zuvor zum Stillstand gekommen sind.
Ursache ist bei großen Steigerungen allerdings meist eine ziemlich schlechte Erst-Implementierung.
Es gibt sehr naheliegende Dinge, die den Einsatz von SP empfehlenswert machen. Viele- auch hier- scheuen sich aber scheinbar davor.
Es sind also nicht nur performancetechnische Betrachtungen im Grenzbereich anzustellen, sondern auch Vereinfachungen und Nachhaltigkeit (schon wieder dieses Wort
) bei der Softwareentwicklung, -weiterentwicklung, -anpassung und -wartung. Gleiches gilt für die
DB. Ich muss offen für Erweiterungen sein: Eine Abstraktionsebene im
DB-Layer(Views und SPs zum Laden und SPs und updateable Views zum Speichern) vereinfachen hier den Entwicklungsaufwand um den Faktor 5 und höher. Demgegenüber stehen jedoch zeitkritische Operationen, wo ich u.U. direkt mit den Daten reden muss (bulk updates z.B.). Hier muss man im Einzelfall entscheiden, inwieweit man die Anwendung abhängig vom konkreten Design machen muss.
Nachhaltig, ist wirklich ein tolles Wort, bzw. der Gedanke, der darin steckt. Es ist in Mode gekommen, als man versucht hat, den Leuten beizubringen, dass man mit klein klein jetzt nicht mehr weiter kommt und für die Umwelt und die Banken und überhaupt nun mal was ordentliches auf die Beine stellen muss. Und wir ahnen es alle, das kostet!
Also Deine Gedanken halte ich nicht für verkehrt, ich bezweifele nur, dass sie dem TE helfen.