[Diskussion] Effektivste Methode Daten aus DB ins Programm

[RWarnecke]

Hallo zusammen,

da ich gerade am planen bin, eine größere Datenbankanwendung zu schreiben, wollte ich mal fragen welche Methoden und Varianten die effektivste ist. Die Möglichkeiten kenne ich :
1.) Ich benutze derzeit für mein Programm Code-Orakel eine einfache Query. In der Query setze ich einen SQL-Befehl ab und hole mir dann über FieldByName oder Fields[x] die Daten aus der SQL-Abfrage.
Beispiel:

Delphi-Quellcode:

with Query do
begin
  SQL.Clear;
  SQL.Text := 'Select * From tabelle';
  Open;
  Active := true;
  while not eof do
  begin
    Memo1.Lines.Add(FieldByName('Name').AsString);
    Next;
  End;
  Active := false;
  Close;
end;

2.) Die Daten über Table und den DB-Komponenten (z.B. TDBEdit) zu holen und anzuzeigen. Diese finde ich aber etwas umständlich und vielleicht auch nicht ganz so flexibel wie die über die Query.
3.) Diese Möglichkeit kenne ich nur von hören sagen und zwar die Daten aus der Datenbank holen und in eine Klasse oder ein Rekord schreiben. Wenn dieses geschehen ist, die Felder (z.B Labels oder Edit-Felder) mit den Werten aus der Klasse oder dem Record füllen.

Jetzt stellen sich mir drei Fragen :
a.) Welche der drei Möglichkeiten ist die effektivste ? (Vor- und Nachteile)
b.) Wie würde die dritte Möglichkeit funktionieren und ablaufen (Ablaufplan und/oder Sourcecodebeispiel)
c.) oder gibt es noch eine andere Möglichkeit die Daten aus einer Datenbank in die Masken des Programms zu schreiben ?

[Bernhard Geyer]

Optimal ist die Verwendung von Stored Procedures die dann einfach aufgerufen wird.
Die zweitbeste Möglichkeit ist die Verwendung von prepared Statements:

Delphi-Quellcode:

myQuery.SQL.Add('INSERT INTO MyTABLE(Feld1, Feld2) VALUES(:Feld1, :Feld2)');
myQuery.Prepare;
for i := 0 to Datensatzcount
begin
  myquery.ParamByName('Feld1').AsString := Datensatz[i].Feld1;
  myquery.ParamByName('Feld2').AsString := Datensatz[i].Feld2;
  myquery.ExecSQL;
end;
myQuery.UnPrepare;

Syntax (Methodennamen) unterscheiden sich je nach verwendeter nativer Zugriffskomponente etwas.

[spaxxn]

Nur mal eine Frage:

Wieso steht eine Klasse zu erstellen überhaupt in der Auswahl?

[RWarnecke]

Zitat von spaxxn:

Nur mal eine Frage: Wieso steht eine Klasse zu erstellen überhaupt in der Auswahl?

Diese Variante kenne ich nur vom hören sagen. Ich kann mir vorstellen, dass ich da eine Trennung zwischen GUI und eigentlichen Programmcode besser realisieren kann.

[chaosben]

Die Nutzung einer Business/Daten-Logik (also Trennung von Daten und GUI) ist für den Entwickler sehr angenehm.
Ich will jetzt nicht die vielen Vorteile aufzählen, weil du nach der Effektivität gefragt hast: Wenn du so eine Zwischenschicht einziehst, leidet die Performance. Nicht viel; eben je nach Implementation.
Die Frage ist: Bist du auf Effektivität angewiesen oder kannst du eine wenig Verlust in Kauf nehmen? Wenn ja dann bau dir unbedingt so eine Logik-Schicht dazwischen. Wenn du später mal was ändern/hinzufügen willst, freust du dir ein 2. Loch in den Hintern weil es so einfach geht. (Das ist meine Erfahrung.)

[QuickAndDirty]

Ja, ein Layer für die Persistenz ist angenehm wenn man es hat, und viel arbeit es nach zu rüsten.
Dann wäre es noch sinnvoll die Datenzugriffskomponenten nicht direkt zu verwenden sondern
den Umweg über eine Fassade zu gehen. Das macht den Code auch dann noch leicht pflegbar wenn sich die
Funktionalität der Komponenten ändern oder sogar andere Komponenten genutzt werden müssen. Immer unter der
Vorraussetzung das man auf so proprietären Unfug wie Stored Procedures verzichtet.

Wenn es allerdings um reine Performance geht sind Stored Procedures die erste Wahl...
...du musst dir halt nur die Arbeit auf jedem SQL-Server von neuem machen.

[RWarnecke]

Zitat von chaosben:

Die Nutzung einer Business/Daten-Logik (also Trennung von Daten und GUI) ist für den Entwickler sehr angenehm.
Ich will jetzt nicht die vielen Vorteile aufzählen, weil du nach der Effektivität gefragt hast: Wenn du so eine Zwischenschicht einziehst, leidet die Performance. Nicht viel; eben je nach Implementation.
Die Frage ist: Bist du auf Effektivität angewiesen oder kannst du eine wenig Verlust in Kauf nehmen? Wenn ja dann bau dir unbedingt so eine Logik-Schicht dazwischen. Wenn du später mal was ändern/hinzufügen willst, freust du dir ein 2. Loch in den Hintern weil es so einfach geht. (Das ist meine Erfahrung.)

Effektivität bedeutet für mich, dass ich am Anfang vielleicht etwas mehr Arbeit habe um dann später bei der Wartung, Pflege u.s.w. Arbeit einsparen kann. Ich hatte mir schon überlegt eine Trennung zwischen Daten und GUI zu machen, nur leider fehlt mir da der Ansatz für die Umsetzung. ich hätte gerne eine gesunde Mischung zwischen einer performanten und effektiven Anwendung. Dazu bin ich auch gerne bereit, gewisse Performanceeinbussen hinzunehmen, wenn ich später bei einer Änderung oder Erweiterung dafür weniger aufwand habe.

Da ich auch mit dem Gedanken spiele es für mehrere Datenbanksysteme das Programm zu Verfügung zu stellen würde sich ja die Trennung von Daten und GUI anbieten. Wie seht Ihr das ? Was habt Ihr dazu für eine Meinung ?

Wie könnte denn ein Aufbau einer Business/Daten-Logik aussehen ? Benutze ich dafür Records, Klassen oder Arrays oder was ?

[nahpets]

Zitat von RWarnecke:

Zitat von spaxxn:

Nur mal eine Frage: Wieso steht eine Klasse zu erstellen überhaupt in der Auswahl?

Diese Variante kenne ich nur vom hören sagen. Ich kann mir vorstellen, dass ich da eine Trennung zwischen GUI und eigentlichen Programmcode besser realisieren kann.

Wir haben bei einem Projekt (nicht mit Delphi) Methoden, die dynamisch aus den Datenbanktabellen entsprechende Zugriffklassen erstellen, die das Lesen, Speichern (Insert und Update), sowie das Löschen übernehmen. Änderungen an der Datenbank führen automatisch zur Anpassung der Zugriffklassen. Abhängigkeiten zwischen Tabellen (1:n-Beziehungen) werden berücksichtigt, so dass z. B. eine Änderung des Schlüssels des Mastersatzes auch die Detailsätze berücksichtigt werden. Als Entwickler der Clientsoftware muss man sich hier quasi um nichts kümmern.
Das Einzige was der Anwendungsentwickler machen muss ist zwei Methoden implementieren, die die schönen Namen ObjektInMaske und MaskeInObjekt heißen. Die Namen dürften selbsterklärend sein.

Vor längerer Zeit habe ich mal versucht, sowas in Delphi zu realisieren. Es geht (weitgehend), ist aber aus Zeitgründen nie bis zur "Serienreife" gekommen.

Zitat von chaosben:

freust du dir ein 2. Loch in den Hintern weil es so einfach geht.

Da ist was dran, einmal ein bisserl mehr Arbeit machen und später sehr viel Arbeit sparen.

[guidok]

[quote="RWarnecke"]

Zitat von chaosben:

Da ich auch mit dem Gedanken spiele es für mehrere Datenbanksysteme das Programm zu Verfügung zu stellen würde sich ja die Trennung von Daten und GUI anbieten. Wie seht Ihr das ? Was habt Ihr dazu für eine Meinung ?

Wie könnte denn ein Aufbau einer Business/Daten-Logik aussehen ? Benutze ich dafür Records, Klassen oder Arrays oder was ?

Da ich selbst auch schon diese
Frage gestellt habe, schau doch da mal nach.

Ich habe die dort erwähnte Möglichkeit (Post #11) für mich vereinfacht und versuche nun auf dieser Basis etwas zustande zu bekommen.

[RWarnecke]

Zitat von guidok:

Da ich selbst auch schon diese
Frage gestellt habe, schau doch da mal nach.

Ich habe die dort erwähnte Möglichkeit (Post #11) für mich vereinfacht und versuche nun auf dieser Basis etwas zustande zu bekommen.

Danke für den Link, werde ich mir heute Abend zu gemüte ziehen.