Hallo zusammen,

ich habe meine Anwendung momentan basierend auf mysql mittels der zeos-Komponenten realisiert. Da die Anwendung mit der Zeit immer komplexer geworden ist sind zumindest potentiell die Chancen gegeben, diese auch kommerziell vermarkten zu können.

Da es sich um eine Business-Anwendung handelt, wird man in der Realität dann wohl weniger mysql in Unternehmen vorfinden, als z.B. Oracle. Dies bedeutet, dass ich meine Anwendung hinsichtlich der anzubindenen Datenbanken "offener" gestalten müsste, z.B. durch Verwendung der ADO-Komponenten.

Da ich denke, dass ich die DB-Zugriffskomponenten in meiner Anwendung relativ einfach durch eine andere Komponente austauschen kann, liegt mein Fokus der Frage mehr auf dem administrativen Part.

Aktuell geht meine Anwendung davon aus, dass irgendwo eine mysql-DB existiert. Mittels eines separaten Adminstrations-Tools, bei dem man sich unter Angabe des DB-Servers und eines Admin-Zugangs anmeldet wird die DB quasi auf Knopfdruck konfiguriert, benötigte User eingerichtet, etc. Bei den Clients der Anwendung muss nur eine Ini liegen, in der der DB-Server hinterlegt ist und alles läuft rund.

Wenn ich jetzt z.B. die ADO-Komponenten verwende, um "offener" zu sein, muss sicher gestellt werden, dass die entsprechenden ODBC-Treiber überall installiert sind, Connection-Strings müssen dynamisch erstellt werden etc.

Wie macht ihr das so auf eurer praktischen Erfahrung, so dass man ein Produkt ausliefern kann und es z.B. unter der Angabe "läuft mit mysql und Oracle" auch "idiotensicher" zu installieren ist?

Danke und Gruß
Igotcha

Wenn ihr das wirklich machen wollt, wird das nicht einfach. Ich rate aber aus anderen Gründen ab.
Du musst auf jeden Fall sicherstellen, dass alle SQL-Statements nach ANSI-SQL programmiert sind.
Dadurch nutzt ihr die optimierten Anweisungen der DB nicht mehr aus.
SQL ist eben nicht gleich SQL.
Oracle ist sehr viel leistungsfähiger als mySQL. Darum kostet es wohl auch Geld (*autsch* nicht so doll hauen).
Mit ODBC schmeisst du eine Menge Performance in den Müll.

Bei der Umsetzung werdet ihr euch auf ähnliche Datenbanken einschränken müssen (z.B.: Interbase, Firebird).
Wenn ihr Oracle unterstützen wollt, solltet ihr auf den direkten Zugriff (also kein ODBC) zurück greifen. Ansonsten habt ihr gegen Mitbewerber keine Chance.

Das ist meine Meinung dazu.

Naja "Ihr" bin ich. Die Anwendung ist ein privates Abfallprodukt meiner beruflichen Tätigkeit.

Es ist keine Anwendung wie SAP, doch durchaus eine, die im Unternehmensumfeld ihre Berechtigung hat. Warum ich überhaupt auf Alternativ-DBs zu sprechen komme ist, dass mir aus der Praxis durchaus Äußerungen der Art "Wie, noch eine DB zu pflegen? Wir haben doch bereits Oracle" geläufig sind.

Was ich auf alle Fälle vermeiden möchte, ist x Versionen des Programms zu erstellen. Und Performance stellt für die Anwendung nicht das Primärkriterium dar, da ich davon ausgehen, dass was auf mysql vernünftig läuft, auch auf "richtigen" DBs entsprechend performt.

Gruß Igotcha

Hallo Du Ihr
Wenn du dich auf ODBC und ANSI-SQL beschränkst, ist der erste Schritt getan.
Dann müsstest du dich im einzelnen noch informieren, wie die Rechte-Vergabe auf den DBs funktioniert. Besser wäre vielleicht, ein Script für die Erzeugung deiner Datenbank-Tabellen und was du sonst noch auf der DB brauchst. Der DB-Administrator soll dann die Einrichtung wie erforderlich machen (Nach deinen Anweisungen).
Dann brauchst du dir auch keine Gedanken über die Administration zu machen. Deine Anweisungen müssen natürlich ausführlich sein.
Dann brauchst du noch den Zugriff auf deine Datenbank (Passwort und Benutzername).

Das sollte es eigentlich sein.

Hallo Igotcha,

noch ein zwei Tips:

Überprüfe mal welche SQL-Datenbanken du alle unterstützen willst und was die so alles können oder auch nicht. Dann versuche eine gemeinsame Schnittmenge für deine Befehle zu finden. Das Problem ist einerseits das ANSI-SQL sehr rudimentär ist und das auch nicht alle SQL-Datenbanken es komplett unterstützen. In ANSI-SQL gibt es z.B. weder Boolean-Datentypen noch Autoincrementfelder. Ich denke nicht das es wirklich was für alle gibt.

Ich denke auf ODBC kannst du komplett verzichten wenn du ADO nimmst, zumindest auf ORACLE und mySQL dürfte das problemlos gehen. Bei Interbase/Firebird wohl nur in der bezahlversion wenn ich mich recht erinnere.


Du hast dir auf jeden Fall was vorgenommen! Viel Spaß.

Danke für die Antworten

Aber ich sehe das nicht so dramatisch und zwar aus einem Grund, den ich oben schon angesprochen habe. Die Client-Applikation kommt mit normalen SELECT-und UPDATE-Befehlen aus. Was mir Kopfschmerzen bereitet ist die von mir angestrebte Benutzerfreundlichkeit im Bereich Administration des Komplettpakets. Also Einrichten der DB, der Datenbankuser, Einrichten und Pflege von Anwendern der Software (diese hat ein eigenes Rechtesystem), Konfiguration der Applikation selbst, etc.

Da wäre es natürlich schön, wenn man dies mit einem Administrations-Tool für mehrere Datenbank-Typen handeln könnte. Auf der Clientseite ist es im Notfall mit dem Einspielen des passenden ODBC-Treibers erledigt - das muss dann zur Not der Systemadministrator vor Ort gem. Anleitung einrichten.

Da das Paket im Moment ausschließlich auf mySQL ausgerichtet ist, müsste ich wahrscheinlich im Bereich Administration ein separates Tool für jeden DB-Typ anfertigen. Nur mal als Beispiel: Die User für den DB-Zugriff bei mySQL befinden sich in der Datenbank "mysql" - die wird es ganz sicher nicht auf z.B. ORACLE geben.

Wobei ich mich dann wirklich auf mySQL und ORACLE beschränken würde.

Gruß Igotcha

Greifst du direkt mit Queries/Datasets auf die Daten zu?
Dann wird's eklig....
Wenn nicht kannst du doch von deinen Zugriffsklassen Ableitungen für Ora & mySQL basteln.

Grundsätzlich: Du musst für Ora eine eigene Instanz anlegen (dein Kunde wird dir sonst auf's Dach steigen ). Darin kannst du die Tabellen fast genauso anlegen, wie du es mit mySQL getan hast. Unterschiede gibt es aber für PKs: Während in mySQL numerische PKs autom. hochgezählt werden können, brauchst du für Oracle die klassische Sequence/Trigger - Kombination.

Problem 2: Erst Ora9 kann die SQL99-Schreibweise für Joins (left, right, outer ,... wobei ich keinen reinen Oracle Entwickler kenne, der diese IMHO etwas hässliche Schreibweise nimmt )
Vor Ora 9 macht man das so:

markieren

SQL-Code:

SELECT X
FROM Y1,
       Y2
WHERE Y2.FK(+) = Y1.PK

d.h. Du kriegst auch die DS aus Y1 ohne Entsprechung in Y2.

Zitat von Robert_G:

kannst du doch von deinen Zugriffsklassen Ableitungen für Ora & mySQL basteln.

Das wollt ich auch grad vorschlagen. Es geht sogar eventuell noch einen Tick einfacher. Ich nehm mal als Bsp du willst nur MySQL und Oracle unterstützen.
Jetzt würde ich für jede Query, Table etc. die du sicherlich schon in einem Datamodul hast, jeweils eine Datasource hinzufügen, welche auf den TDataset Abkömmlich verweist. Beim Programmstart prüfst du dann, ob du MySQL oder Oracle verwendest, und linkst deine Datasource.Dataset Eigenschaft entsprechend. Das setzt natürlich voraus, daß du alle Queries in doppelter Form vorliegen hast, also eine MySQL und eine Oracle Variante.

Damit hast du das Gröbste schon getan. In deinem Programm selbst musst du dann nur immer peinlichst genau darauf achten, daß du deine Queries nie direkt ansprichst, sondern immer nur über die entsprechende Datasource.Dataset Verbindung.

Ist sicherlich nicht der vorbildhafteste Weg, aber in der Umsetzung denk ich recht einfach.

Gruß,

Hmmm, ganz dumme Frage... wenn ich mich auf die 2 genannten DBs konzentriere und ich nach Euren Vorschlägen dann sowieso alles doppelt halten müsste, warum kann ich dann nicht gleich das hier machen?

markieren

Delphi-Quellcode:

if strDB='ORACLE' then // DB-Typ wird beim Programmstart abgefragt
   Query.Sql.Text:='blablablah'
else
   Query.Sql.Text:='lalala';

Query.Open (oder Query.ExecSQL);

Gruß Igotcha

Hallo Igotcha,

wenn du doch schon die ZEOS-Komponenten benutzt, dann dürfte es doch keine Schwierigkeit sein, auch andere Datenbanken damit anzusprechen! Die Version 6.5.0 (momentan leider noch alpha) unterstützt auch Oracle9i. Ich hab's mal flüchtig getestet und muss sagen, dass ich keinerlei Schwierigkeiten damit hatte. Und wenn du sowieso nur SQL benutzt, dass auf allen von dir zur Verwendendung vorgesehenen DBs läuft, dann ändern sich im Endeffekt nur die Verbindungsparameter. Und die lassen sich ja locker in der ohnehin schon verwendeten Ini-Datei speichern.
Und für die Fälle, wo sich die Vorgehensweisen aufgrund der Datenbank-Struktur unterscheiden, musst du innerhalb des Programms Fallunterscheidungen treffen.