Empfehlung zur offenen Gestaltung von DB-Anwendungen gesucht

[Igotcha]

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

[Jasocul]

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.

[Igotcha]

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

[Jasocul]

Hallo Du Ihr :wink:
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.

[UweR]

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ß.

[Igotcha]

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

[Robert_G]

Greifst du direkt mit Queries/Datasets auf die Daten zu? :shock:
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:

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.

[Jelly]

Zitat:

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ß,

[Igotcha]

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?

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

[Stevie]

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.

[mschaefer]

Hallo Stevie,

also für die Standartsqlabfragen scheint das mit ZEOS sehr gut zu funktionieren.
Hast Du mal etwas mit Funktionen in SQL-Abfragen gemacht. Da hatte ich allerdings
bei bei 6.1 noch ziemlich Probleme, da ZEOS die Funktionswörter (z.B. "CAST") als
Fehler reklamierte.

Grüße // Martin

[Igotcha]

Ja, da habe ich so mein Problem mit ;-)

Ich benutzte: 6.1.5-stable build at 2004-04-29 07:03:04

Irgendwie habe ich als "Protokoll" aber keine Oracle als Auswahl :gruebel:

Gruß Igotcha

P.S. Sorry, habe gerade gesehen 6.5 unterstützt Oracle. Werde ich dann mal updaten und testen, danke!

[Stevie]

Ne, mit Prozeduren hab ich zumindest unter MySQL oder Oracle nicht mit ZEOS gearbeitet.

Zitat:

Die Version 6.5.0 (momentan leider noch alpha) unterstützt auch Oracle9i.

:wink: Teste die Sache doch einfach mal mit dieser Version. (Hier zu bekommen)

[Igotcha]

So, habe jetzt erstmal zeos auf 6.5 upgedated. Hat etwas gedauert, da ich alle zeos-Komponenten im Programm ersetzen musste - einige Poperties haben sich geändert.

Mit mySQL läuft es wie gewohnt sehr gut und am Wochenende werde ich mir das Ganze mal mit Oracle anschauen und berichten.

Gruß Igotcha

[Robert_G]

Zitat:

Zitat von Stevie

Die Version 6.5.0 (momentan leider noch alpha) unterstützt auch Oracle9i.

Eine Alpha/Beta/Irgendwas Version auf eine Ora-DB? :shock:
Das kannst du echt nicht bringen. ;)
Wenn bei deinem Kunden Oracle läuft, dann hat das seinen Grund. Wurschtelst du jetzt mit Software auf dem Server rum, die weder final noch validiert ist, hebst du theoretisch sämtliche Hardware/Software Validierung auf, die dort bisher gültig war.
Soll heißen: Du verwandelst damit im Endeffekt jede DB, die dort läuft, in eine Alpha/Bata. :shock: Das mag jetzt wie Erbsenzählerei klingen, aber eine Ora-DB läuft nicht um sich ein paar Kugelschreiber zu sortieren.
Darauf kann die gesamte Firmenlogik aufbauen (Die nunmal bis ins kleinste Detail validiert werden muss. )

[Stevie]

Zitat:

Zitat von Robert_G

Zitat:

Zitat von Stevie

Die Version 6.5.0 (momentan leider noch alpha) unterstützt auch Oracle9i.

Eine Alpha/Beta/Irgendwas Version auf eine Ora-DB? :shock:
Das kannst du echt nicht bringen. ;)
Wenn bei deinem Kunden Oracle läuft, dann hat das seinen Grund. Wurschtelst du jetzt mit Software auf dem Server rum, die weder final noch validiert ist, hebst du theoretisch sämtliche Hardware/Software Validierung auf, die dort bisher gültig war.
Soll heißen: Du verwandelst damit im Endeffekt jede DB, die dort läuft, in eine Alpha/Bata. :shock: Das mag jetzt wie Erbsenzählerei klingen, aber eine Ora-DB läuft nicht um sich ein paar Kugelschreiber zu sortieren.
Darauf kann die gesamte Firmenlogik aufbauen (Die nunmal bis ins kleinste Detail validiert werden muss. )

Du hast natürlich recht! Er soll ja auch nicht seine Software mit den Kompos in diesem Stadium releasen!!!
Aber um die grundlegende Funktionalität zu testen und schonmal einzubauen, kann er doch wohl diese Version benutzen!?

[Robert_G]

Ich bezweifle viel mehr, dass die Zeos überhaupt jemals eine solche (verdammt aufwendige) Validierung erfahren. ;)

[Stevie]

Zitat:

Zitat von Robert_G

Ich bezweifle viel mehr, dass die Zeos überhaupt jemals eine solche (verdammt aufwendige) Validierung erfahren. ;)

Das mag natürlich sein... :gruebel: Aber dafür sind sie eben auch "nur" OpenSource und generisch, und beispielsweise nicht mit den DOA-Komponenten vergleichbar, die extra für Oracle entwickelt wurden - und einen dementsprechenden Preis haben... ;-)

[Marcel Gascoyne]

Wenn die Anwendung unabhängig von der Datenbank sein soll würde ich ein Objekt-Persistentes Framework empfehlen. Es gibt da z.b. zwei Interessante Produkte für Delphi.

Zum ersten das BOLD Framework, welches allerdings nur in der Architect Version von Delphi 7 vorhanden ist. Genaugenommen ist das der einzige Unterschied zwischen der Enterprise und der Architect. Dieses Framework ist sehr mächtig aber leider auch sehr teuer.

Eine kostengünstige Alternative ist InstantObjects, welches bis vor ca. einem Jahr noch kommerziell von Seleqt vermarktet wurde. Mittlerweile ist es Open Source (http://www.instantobjects.org).

Im Gegensatz zu einer normalen Datenbank arbeitet man nun mit Objekten, die auf physikalische Tabellen in der Datenbank gemappt sind. Diese persistenten Klassen werden entweder mit einem Model Explorer in der Delphi IDE angelegt oder auch mit dem Model Maker.

Der Zugriff auf die Daten erfolgt nun nicht mehr mit SQL sondern mit einer eigenen Abfragesprache für Objekte die stark an SQL angelehnt ist, wie z.b.

SQL-Code:

select * from TKunden where Name = 'Muster'

Nebenbei kann man diese Datenklassen auch mit Ereignissen versehen.

Die entsprechende Datenbank wird auf Knopfdruck automatisch erzeugt.

Derzeit werden von InstantObjects folgende Datenbanken unterstützt: MS-SQL, Sybase, Interbase, Firebird, DBISAM, ADS, NexusDB, FlashFiler, DBase, Paradox und XML-Files.

Wichtiger Hinweis noch: Das Projekt wird bei Sourceforge gehostet (http://sf.net/projects/instantobjects), die downloadbare Version ist noch 1.6. Wenn man die aktuelle 1.7er haben möchte muss man sich diese aus dem CVS auschecken (Empfehlenswert!).

Gruß,
Marcel

[Igotcha]

Hallo Marcel,

ich habe mich jetzt auf mysql und Oracle beschränkt und ich denke, das ist für mein Programm auch ausreichend.

Trotzdem ist der Tipp von Dir sehr interessant! Ich werde mir das auf alle Fälle anschauen.

Danke und Gruß
Igotcha