ADO +Interbase und auch noch ohne SQL

[danielA]

Hallo alle zusammen,

ich arbeit gerade an einem Projekt, daß auf eine Interbase (6.01) aufbauen soll. Da ich aber Datenbankunabhängig bleiben möchte, habe ich mich gegen die in Delphi enthaltenen Interbasekomponenten entschieden und möchte das ganze lieber über ADO, mit möglichst wenig SQL machen. Ich habe nun schon einige Provider und ODBC-Treiber ausprobiert (sowohl Opensource, als auch Trialversionen von kommerziellen Produkten), mein Erfolg war jedoch eher mäßig. Entweder funktionierten sie nur teilweise, oder spätestens bei einem ADODataSet.Lookup() stellte sich heraus, daß sie aus Performancegründen nicht zu gebrauchen sind (eine Abfrage die via SQL etwa 0,5 s dauert dauerte über Lookup min 12 s) über Stored Procedures wollen wir lieber gar nicht erst reden. Nun zu meiner eigentlichen Frage. Weiß jemand von euch wie ich möglichst Datenbankunabhängig, ohne (oder mit wenig) SQL mit einer akzeptablen Zugriffszeit auf eine Interbasedatenbank zugreifen kann.

Danke schon mal im vorraus

Gruß

danielA

[Hansa]

Hi,

mit sowas habe ich mich (zu) lange beschäftigt. Deshalb zerpflücke ich das da mal (anhand meiner Erfahrungen) :

Zitat von danielA:

ich arbeit gerade an einem Projekt, daß auf eine Interbase (6.01) aufbauen soll. Da ich aber Datenbankunabhängig...

kannste vergessen, sei froh wenn Du alles überhaupt für eine DB richtig zusammen kriegst.

Zitat:

...mit möglichst wenig SQL machen.

Interbase ohne SQL ist wie Auto ohne Motor oder Reifen und 10m breit, als Schwertransport.

Zitat:

...ODBC-Treiber ausprobiert (sowohl Opensource, als auch Trialversionen von kommerziellen Produkten), mein Erfolg war jedoch eher mäßig.

siehe oben. Da passt dann nichts mehr.

Zitat:

...Nun zu meiner eigentlichen Frage. Weiß jemand von euch wie ich möglichst Datenbankunabhängig, ohne (oder mit wenig) SQL mit einer...

Dem ist wohl nichts mehr hinzuzufügen. Falls doch, bin ich gespannt.

PS: IB OpenSource wird von keinem mehr unterstützt und ist deshalb sowieso zumindest scheintot Wie oft schreibe ich das die letzte Zeit so oft ?

[danielA]

Hallo nochmal,

Danke erstmal für die Antwort.

Ich habe heute mal mit dem Provider von zstyle rumexperimentiert und recht Gute Ergebnisse erziehlen können. Eigentlich die besten bisher. Ich sehe zwar in deren Lizenzmodell noch nicht so wirklich durch (wann freie Nutzung und wann kaufen) aber das kriege ich auch noch raus.

Hier der Link.

http://www.zstyle.dp.ua/eng/index.htm

Gut, ganz ohne SQL gehts wohl nicht aber ich denke mit einem "Select * from Table" kann man leben um in einem DBGRID Daten anzeigen zu können und in der Lage zu sein diese dann zu ändern. Dieser Provider ist sogar in der Laage Parameter von Stored Procedures richtig zu lesen und zu setzen. Das klingt Simpel war aber mit den anderen leider nicht oder nur eingeschränkt möglich.

So schlimm wie du es beschrieben hast ist es Glücklicherweise dann doch nicht mehr.
Ich finde es dennoch schade, daß so ein Datenbanksystem mit recht hoher Performance, sowie Funktionalität so wenig Unterstützung findet.

Gruß danielA

[bis]

Hi,

wenn ich Dir einen Tip geben darf. Mach so viel wie möglich über SQL. Ich habe bis jetzt nur gute Erfahrungen damit gemacht und von der Performance her ist es auch nicht zu verachten. Des Weiteren, kannst Du als Nachfolger von IB 6.0 OpenSource die FirebirdSQL nehmen. Dieses ist auch ein Open-Source-Projekt und baut auf der IB 6.0 Open-Source auf.

[harrybo]

Hi danielA,

ich musste Deinen Text zweimal lesen, um ihn zu verstehen. Du suchst Datenbankunabhängigkeit und möchtest daher auf SQL verzichten. Ich kenne das nur anders herum: Man versucht möglichst viel in SQL zu machen, um mit geringem Aufwand flexibel auf- bzw. umsteigen zu können.

Nun ja, da Deine Anforderungen an den Server maximal bis "Select * from Table" gehen, könntest Du Dir Deinen Wunsch nach Datenbankunabhängigkeit erfüllen, indem Du gänzlich auf den Einsatz einer Datenbank verzichtest, und in ein oder mehrere Text-, bzw. Binärdateien schreibst. Die werden diesem Anspruch allemal gerecht.

lieben Gruß, harrybo

[Lemmy]

Hi DanielA,

erst mal gebe ich meinen Vorrednern in allem Recht:
Wirkliche Performance bekommst Du nur, wenn Du auf SQL nicht verzichtest sowie Spezialitäten der Datenbank (Stored Procedures,...) voll ausschöpfst.

Allerdings hast Du dann das Problem mit der Unabhängigkeit, jedoch hast Du mit OOP alle Möglichkeiten dieses Problem zu umgehen:

Teile Deine Applikation in 3 Schichten:

1. Schicht: Datenbank
2. Schicht: Verbindung DB-Appliaktion
3. Schicht: Applikation

Die 1. Schicht existiert schon: die eigentliche Datenbank. Die 3. Schicht existiert im Prinzip auch schon: die Dialoge und Formulare Deiner Appl. Du musst jetzt die 2. Schicht, also die Verbindung zur Datenbank, mittels OOP so erstellen, dass Du für ne andere Datenbank "einfach" von deinen Zugriffsklassen ne Ableitung machst und die dann auf die entsprechende Datenbank anpasst. Alles unklar?
Hier in dem Artikel http://www.h-k.de/oop/artikel_oop.zip kannst Du noch die komplette Theorie nachlesen.

Grüße
Lemmy

[danielA]

Hallo erstmal,

ich habe bis eben an meinem neuen Router rumgeschraubt und bin gerade erst wieder online, deshalb auch meine verspätete Antwort.

@bis
In meinen bisherigen Projekten habe ich es auch so gehalten, mußte aber feststellen, daß diese Projekte schwerer zu warten und an andere Datenbanken anzupassen waren, daher grübel ich ja nun über Alternativen die mir das erleichtern.

@harrybo
Nunja, auf Datenbanken zu verzichten, der Gedanke gefällt mir ganz und gar nicht. Einen Datenbaestand von min. 1 Mio. Datensätzen läßt sich da wohl auch kaum in Textdateien mit einer passablen Geschwindigkeit halten. Datenbankunabhängig ist es dann schon, nur wie erkläre ich das dem Kunden wenn er von mir erwartet, daß ich mein System in seine bestehende Datenbank mit einbaue. (Live also ohne Export und Import von Daten aus meinem Datenbankunabhängigemachtenimklartextleserlichensu perturbotextdatenbanksystem )


@Lemmy
ich habe mir die Datei gerade heruntergeladen und werde sie wohl nach dem aufstehen mal durcharbeiten. Ich denke, laut deiner Erklärung, ich habe es ähnlich begonnen. Ich habe mir eine virtuelle Klasse gebaut, deren Kindklassen auf die Dataset der Datenbank zugreifen sollen. Diese Virtuelle Klasse führt Methoden und Eigenschaften ein, welche von den Kindklassen übernommen werden müssen. In diesen Klassen wird mit SQL gearbeitet. Nun wiederum ein paar visuelle Klassen, welche mit der Schnittstelle zu der virtuellen Klasse klarkommen und es sollte funktionieren.

Danke nochmal an alle für die Hilfe

Gruß danielA

[harrybo]

Hi danielA,

ich sag's mal anders: Wer mit SQL nichts am Hut haben will, sollte sich nicht auf Datenbanken einlassen. Deinen Beschwerden bzgl. Performance lässt sich eher entnehmen, dass Du möglicherweise einige Kniffe nicht kennst (z.B. DisableControls, oder der mögliche Performancekiller TDataSource.OnDataChanged, oder das Verwenden von TTable überhaupt...). Ich vermute ohnehin, dass Deine Performanceprobleme mit Deinen datensensitiven Objekten, sprich der Datendarstellung und nicht mit der Abfrage selbst zu tun hat. Von Stored Procedures willst Du gar nicht erst reden, uups, was soll denn bei einer serverbasierten Datenbank schneller sein? Abgesehen davon, wenn Deine Tabellen über 1 Mio. Datensätze aufweisen, ist zu bezweifeln, ob 'SELECT * FROM <Tabelle>' der richtige Ansatz ist. Das Delphi DBGrid dürfte Deinem anscheinend hohen Performanceanspruch jedenfalls nicht gewachsen sein.

Lieben Gruß

harrybo

[danielA]

Hallo harrybo

DisableControls kannte ich wirklich noch nicht. Aber jetzt Danke !
Wie ich im letzten Beitrag schon schrieb, Teile ich das Projekt wie von Lemmy vorgeschlagen auf und dafür nutze ich eigentlich ausschließlich TDataset um auf die DB zuzugreifen.

Nun zu meinem Performanceproblem: es gibt noch keins.
Das Projekt steht noch recht weit am Anfang. Mir sind die Probleme der Datacontrols schon seit längerem bekannt. Bis jetzt habe ich die SQL-Statements aufwendig dynamisch erzeugt, was beim Wechsel zu einem anderen Datenbanktyp leider problematisch ist (Man denke an die dynamische generierung eines join + zugehöriger insert update und delete Statements für die in dem join angezeigten Tabellen).

Das mit den Stored Procedures scheinst du falsch verstanden zu haben.
Im Gegenteil ich nutze sehr gerne Stored Procedures. Mann sollte den Clients doch möglichst viel abnehmen, umso sicherer ist die Sache.

Was ich mit meiner Aussage meinte war lediglich auf die ODBC-Treiber und Provider bezogen, die ich ausprobiert habe. Es war kaum einer darunter, der mir eine Executable Procedure korrekt ausführen konnte.

Bei dem DBGrid stimme ich dir komplett zu, es ist für solche Datenmengen absolut ungeeignet.
Ich habe mir dafür bereits mit Hohem Aufwand über das Stringgrid Ersatz geschaffen mit akzeptabler Geschwindigkeit, einem Real funktionierenden Scrollbar und ohne unnötig Daten zu schaufeln.

Grüße danielA

[harrybo]

Hallo danielA,

jetzt verstehe ich schon bedeutend besser. Leider willst Du auf die Verwendung der IBX Komponenten verzichten. Die nähmen Dir einiges an Arbeit ab, wie z.B. die Erstellung der entsprechenden SQL Statements für Update, Insert, Delete, sowie automatisches Parameter Handling. Außerdem können zwei IBDataset per Definition im Objekt Inspector als Master Detail fungieren, man muss lediglich eine TDatasource zwischenklemmen (der einzige Grund, warum ein TIBDataset überhaupt das Property DataSource besitzt). Voraussetzung hierbei ist allerdings, dass der Name des Master Primärschlüsselfeldes und der Name des Detail Fremdschlüsselfeldes identisch sind. Die Performance hierbei ist umwerfend, auch bei sehr hohem Datenaufkommen.

Deinen Stored Procedures Hinweis habe ich dann wirklich falsch verstanden. Es stand aber auch direkt im Zusammenhang mit Deinen Performance Befürchtungen. Was Dein DBGrid angeht, hoffe ich, war Dein Aufwand nicht zu hoch, was hast Du denn gemacht? Deine Lösung ist vielleicht für andere hier im Forum auch interessant. Ich selbst habe keinen Aufwand betrieben und mir einfach eins gekauft ;-)

Ich drücke Dir jedenfalls die Daumen für Dein Vorhaben

lieben gruß, harrybo