[Diskussion] Effektivste Methode Daten aus DB ins Programm

[RWarnecke]

Zitat von guidok:

Ich habe gerade noch etwas gefunden. Bin mit dem Durchlesen noch nicht fertig, aber könnte interessant sein...

Was ich so aus diesem Tutorial rauslese ist ja, dass die einfachste Methode über ein TDataSet ist, wenn ich selber soetwas erstellen will. Desweiteren stört mich, dass in dem Tutorial über TDBEdit Felder gegangen wird. Ich persönlich hasse diese Komponenten, ich bin bis heute nie damit richtig zurecht gekommen. Ich tendiere immer mehr dazu, dass in einer ähnlichen Art wie Detlef zu machen.
Ich habe ein Datenbankmodul, wo die TIBQuery, TDataSource und die anderen Komponenten für die Datenbankverbindung drinstehen. Beim Initialisieren des Datenbankmoduls wird die Verbindung zur Datenbank hergestellt. Dazu kommen in das Modul noch die ganzen Funktionen/Proceduren für die Abfragen, die ich sonst im Sourcecode der Anwendung untergebracht hatte. Das heißt, ich rufe die Proceduren/Funktionen aus dem Modul direkt aus dem Sourcecode der Hauptanwendung auf und übergebe die Werte der Form an die Funktion/Procedure.
Den Vorteil darin sehe ich, ich habe eine eigene Unit/Modul welches alle Aufgaben der Datenbank erledigt. Bei einer eventuellen Umstellung der Datenbankkomponenten müsste ich nur diese eine Unit anfassen, was natürlich von Vorteil wäre. Mir ist auch klar, dass das kein reines OPF ist. Aber es wäre eventuell eine alternative. Was meint Ihr dazu ?

Das ganze könnte man ja dann noch weiter ausbauen und sich damit eine eigene DLL basteln, die mehrere Datenbanken unterstützt. Das sind erstmal meine Gedanken dazu.

[alzaimar]

Zitat von guidok:

Der größte Nachteil den ich sehe ist, dass du durch die Views und SP sehr dicht an der DB arbeitest. Ein Wechsel der DB oder das Speichern z.B. in XML wird damit sehr schwierig...

Ich weiß aus eigener leidvoller Erfahrung, dass was in MSSQL funktioniert, in MySQL völlig anders ist.

Das kann ich nicht nachvollziehen. Durch vollständige Kapselung der Datenbank-Perversionen erreiche ich doch gerade eine Datenbankunabhängigkeit. Nun gut, die neue Datenbank muss zumindest die Grundzüge eines SQL-RDBMS (aka Views und Stored Procedures) beherrschen. Da fällt MySQL natürlich runter. So wie Access und DBase auch.

[nahpets]

Hallo,

Zitat von guidok:

Der größte Nachteil den ich sehe ist, dass du durch die Views und SP sehr dicht an der DB arbeitest. Ein Wechsel der DB oder das Speichern z.B. in XML wird damit sehr schwierig...

Ich weiß aus eigener leidvoller Erfahrung, dass was in MSSQL funktioniert, in MySQL völlig anders ist.

dachte, dass sei der Vorteil, Programmlogik wird von Datenbanklogik getrennt.
Je nach Datenbank sehen die dort implementierten Teile (im schlimmsten Fall) sehr unterschiedlich aus, aber am Programm muss nichts geändert werden. Von z. B. MSSQL solltes Du so ohne Programmänderungen nach Oracle kommen, auch wenn die SQL-Dialekte doch einige (nicht unerhebliche) Unterschiede aufweisen. Und bei den SP's dürften die Unterschiede schon gigantisch sein. Aber Dein Programm sollte da nicht kratzen.

[DeddyH]

Eben deswegen hatte ich mich ja auch dafür entschieden, soviel Funktionalität wie möglich in die DB statt ins OPF zu verlagern.

[khh]

Zitat von DeddyH:

Eben deswegen hatte ich mich ja auch dafür entschieden, soviel Funktionalität wie möglich in die DB statt ins OPF zu verlagern.

hat wohl beides Vor- und Nachteile.


ich denke, wenn die DB gewechselt wird müssen die SP neu erstellt werden.
Also kann ich die Statements auch im Programm anpassen bzw. austauschen.

Ist die "theoretische" Kapselung der Funktionalität so ein Vorteil?

Oder gibts ne Möglichkeit die SP und Views zwischen den RDBMS auszutauschen?

Gruss KH

[RWarnecke]

Zitat von khh:

Ist die "theoretische" Kapselung der Funktionalität so ein Vorteil?

Oder gibts ne Möglichkeit die SP und Views zwischen den RDBMS auszutauschen?

Gruss KH

Ich finde schon, dass ich im weiteren Verlauf dadurch schon mehr Vorteile habe. Den einzigsten größten Nachteil, der mir im Moment auffällt ist der, wenn ich sehr viel Funktionalität in die DB packe. Da bin ich wiederum nur auf RDBMS angewiesen, die SP und Views unterstützen. Wenn ich jetzt das ganze in einer Unit in Delphi mache, bin ich da unabhängiger von der Datenbank.

[nahpets]

Hallo,

Zitat von khh:

ich denke, wenn die DB gewechselt wird müssen die SP neu erstellt werden.

Ja, aber auch nur die.

Zitat von khh:

Also kann ich die Statements auch im Programm anpassen bzw. austauschen.

50 Kunden und 10 unterschiedliche Datenbanken und davon noch jeweils 5 unterschiedliche Versionen.
Und nu?

Zitat von khh:

Ist die "theoretische" Kapselung der Funktionalität so ein Vorteil?

Die theoretische nicht, aber die praktische.

Zitat von khh:

Oder gibts ne Möglichkeit die SP und Views zwischen den RDBMS auszutauschen?

Die Rechnung hast Du dann ohne die Datenbankhersteller gemacht.
Stell' SQLs für Massendatenverarbeitung, die für Oracle optimiert sind, um auf MS-SQL, MySQL, Firebird, Postgres, Ingres...
ff oder Fiel Fergnügen, wie man bei uns im Rheinland sagt

[mkinzler]

Zitat:

Stell' SQLs für Massendatenverarbeitung, die für Oracle optimiert sind, um auf MS-SQL, MySQL, Firebird, Postgres, Ingres...

Für FireBird könnte man sich dann Fyracle anschauen.

Aber ich bin auch die Meinung das die Kapselung wenn möglich ins DBMS gehören ( SPs). So entlastet man auch den Client und vereinfacht das Deployment/Update der Anwendung

[khh]

Zitat von mkinzler:

Zitat:

Stell' SQLs für Massendatenverarbeitung, die für Oracle optimiert sind, um auf MS-SQL, MySQL, Firebird, Postgres, Ingres...

Für FireBird könnte man sich dann Fyracle anschauen.

Aber ich bin auch die Meinung das die Kapselung wenn möglich ins DBMS gehören ( SPs). So entlastet man auch den Client und vereinfacht das Deployment/Update der Anwendung

unter diesem Aspekt, gebe ich euch Recht.

Was aber, wenn ich selbst entscheide mit welchem RDBMS ich meine Anwendungen erstelle und verkaufe?
Und dabei bleibe ich bei einem RDBMS.


Wo ist dann noch der gepriesene Vorteil ?

Gruss Kh

[mkinzler]

Du kannst nachträglich die Struktur der Datenbank ändern ohne das Programm anfassen zu müssen