Generelle Frag zu ADO

**hermannhass**

Hallo
ich entwickle seit Geraumen eine komplexe Datenbankapplication unter D2006 aber (noch) in Win32.
Als Datenbanken verwende ich MS-Server und Mysql, programmunabhängig über eine eigene
sql-Bridge. Als Zugriffskomponente verwende ich ADO.
Da ich alle DB-VCL's wie DBGRID/DBEDIT selber aus Effizienzgründen geschrieben habe,benötige ich auch keine Datasource. Hierzu habe ich ein eigenes sehr effienentes Messagesystem.
Gerne würde ich noch die ADO-Komponenten ersetzen, da mein Program langlebig sein soll. ZEOS ist mir zu langsam,
gibt es Alternative, evtl sogar direkt auf die sqlServer zuzugreifen?
Ich bin sehr unglücklich kmit den asnychronen Datafetching, benötige aber in einigen Modulen
diese blockweise Übertragung mit "Atempausen".
Vielleicht hat der eine oder andere ähnliche Denkansätze.
Gruß aus der Sonne
Hermann

**Bernhard Geyer**

Bridge-Pattern ist schon gut, aber bitte nicht ADO für MySQL.
Die schnellste Komponenten die ich kenne ist von

Core Labs. Die ADOExpress-Wrapper haben noch einige Bremsen eingebaut die das leben für "normale" DB-Anwendungen vereinfachen, aber u.U. gewaltig Performance kosten (Bestimmung der AutoInc-Spalten bei jedem Select).

Was meinst du genau mit "blockweise Übertragung mit "Atempausen"."? Serverseitige Curser?

**hermannhass**

Erstmal Danke für Deine Antwort und Deine Gedanken.....
>Bridge-Pattern ist schon gut, aber bitte nicht ADO für MySQL.
Warum? Würde mich interessieren. Was dann?
Benutze zur Zeit für mysql natürlich kein ODBC sondern myoleDB.
Also, ich benutze ADO sowohl für MS-Server als auch für mySQL.
Von den ADO's brauche ich nur das adodataset, um an die Recordsets zu kommen.
Die sqlbefehle bastelt mir eine eigenes sqlConfig-Object, das je für MSServer, mysql, (und auch Oracel)
eine Configdatei benutzt und somit mein sql Serverunspezifisch ist.
Da ich keine grundsätzlich keine Fremdkomponenten verwende und auch alle DB-spezifischen
VCL'S wie DBEDIT,DBGRID,DBxxxx selbst entwickle, würde ich auch gerne statt den ADO-DATASET
eine eigene Komponente entwickeln. Ich muss nur Commands absetzen können und halt die
Ergebnisse der queries empfangen. Schnickschnack wie Fields, Parameter, Filter brauche ich nicht.

>Was meinst du genau mit "blockweise Übertragung mit "Atempausen"."? Serverseitige Curser?
Mit Blockweise übetragung meine ich asynchrone Datenübertragung, wenn ich z.B. eine Liste ausgebe
oder ein Grid fülle. Ideal wäre, wenn ich z.b. eine grosse datenmenge auf dem Server initialisiere
und blockweise dann in 100'er Paketen satzweise abholen kann.

Mein gesammtes Programm basiert datenbanktechnisch nur auf das senden von Commands wie Insert/Update/Delete und halt select-Befehlen. "Master/Clients"-beziehungen und sowas mache ich grundsätzlich nativ, als lowellevel sql-queries.

Somit würde mir eine einfache Schnittstelle reichen, die ADO's sind mir im prinzip schon zu komplex und
für die Zukunft zu unsicher, was Performance, Fehler und Eeiterentwicklung angeht.

**Bernhard Geyer**

Zitat von hermannhass:

Erstmal Danke für Deine Antwort und Deine Gedanken.....
>Bridge-Pattern ist schon gut, aber bitte nicht ADO für MySQL.
Warum? Würde mich interessieren. Was dann?

Warum: Nötige Installation, viel zu viele Zwischenschichten die Fehlerquelle darstellen können.
Was dann: Für MySQL würde ich von Core Labs die TDataset-Basierenten Komponenten verwenden.

Zitat von hermannhass:

... Da ich keine grundsätzlich keine Fremdkomponenten verwende ....

Komisch. Ohne Fremdkomponenten hätte unsere Anwendung 50% weniger Funktionalität

Zitat von hermannhass:

Schnickschnack wie Fields, Parameter, Filter brauche ich nicht.

Filter sehe ich ein. Aber keine Parameter. Schon mal was von SQL-Injection gehört? Wenn du pech hast
und nicht wirklich alles Hieb und Stichfest quotest würdest du bei einem Sicherheitsaudit mit Posaunen und Tropeten durchfallen.

Zitat von hermannhass:

Mit Blockweise übetragung meine ich asynchrone Datenübertragung, wenn ich z.B. eine Liste ausgebe
oder ein Grid fülle. Ideal wäre, wenn ich z.b. eine grosse datenmenge auf dem Server initialisiere
und blockweise dann in 100'er Paketen satzweise abholen kann.

Da heist es dann 3-Schicht Architektur. ADO kann zwar von sich aus sowas, aber da der MySQL-Server keine Serverseitigen Curser unterstützt muss dieser erst alles "Loswerden" damit du weiter mit der Connection arbeiten kannst.

Zitat von hermannhass:

Somit würde mir eine einfache Schnittstelle reichen, die ADO's sind mir im prinzip schon zu komplex und
für die Zukunft zu unsicher, was Performance, Fehler und Eeiterentwicklung angeht.

ADO.NET ist mit der DB-Ungebundenheit nicht schlecht. Haben selbst sowas (um einigen Stufen einfacher gestrickt) selbst in unserer Anwendung.

**Phoenix**

Zitat von Bernhard Geyer:

ADO.NET ist mit der DB-Ungebundenheit nicht schlecht. Haben selbst sowas (um einigen Stufen einfacher gestrickt) selbst in unserer Anwendung.

Das ist leicht untertrieben

Ich habe letztens 'auf die Schnelle' eine Oracle-basierte .NET Anwendung auf die ADO.NET Interfaces gehoben, die ganzen Statements durch stored procedures ersetzt (also die SP's sozusagen als Schnittstelle zur beliebigen Datenbank definiert) und diese dann parametrisiert über die Interfaces angesprochen.

Hat mich knapp zwei Tage gekostet. Der größte Aufwand war es, das Datenbankschema auf MS SQL und Firebird zu hiefen und die SP's für diese Datenbanken zu schreiben. Und nach zwei Tagen konnte die Anwendung nicht nur Oracle sondern eben aus den SQL-Server und FB. So macht dann Datenbankentwicklung Spass

**hermannhass**

>Komisch. Ohne Fremdkomponenten hätte unsere Anwendung 50% weniger Funktionalität
Ich verzichte einerseits auf Fremdkomponenten, um nicht bei Updates (Delphiversion) trotz (erworbenen) Sourcecode
mal auf dem Schlauch zu stehen, aber hauptsächlich aus Performancegründen.
Viele Fremdkompos haben zwar viele mühsam zu programmierende Features, aber meistens brauch man lediglich 30.50% und zahlt den Rest mit Effizienzverlusten. Habe z.B. zumn Thema GRID/DBGRID und Treeview viele
compos getestet. Selbst professionelle wie TMS, die zwar super sind, gehen schnell in die Knie was Geschwindigkeit angeht. Selbst das normale Delphi Treeview ist um einen 3 stelligen Faktor langsamer als ein Grid.
Facit: Habe mit ein komfortables treeview aus einem selbstentwickelteten Grid entwickelt.
Über eine Property habe ich sowohl grid als auch treeview Funktionaliät & und Aussehen.
Und gigantische Geschwindigkeitsvorteile.

Zum Thema zurück: sql-Injection...
soweit ich weiss, werden parametrisierte Befehle im Client substituiert und zum Server genauso geschickt, als wenn man die Parametersubstition direkt macht.
Ausserdem kann ich immer noch für die Server-Client Kommunikation ein Encrypt/Decrypt Modul zwischenschieben.
Das Thema Sicherheit ist wichtig, wenn ich mich da irre, was die Parameterauswertung angeht, bin ich für jede Korrektur meiner Aussage dankbar.

>Da heist es dann 3-Schicht Architektur. ADO kann zwar von sich aus sowas, aber da der MySQL-Server keine >Serverseitigen Curser unterstützt muss dieser erst alles "Loswerden" damit du weiter mit der Connection arbeiten >kannst.
Das ist mir klar, deshalb hatte ich schon mal an einen serverseitig vorgeschalteten Kommuniaktionsserver gedacht.Nachteilig ist, dass die bei Web-Basierten Servern nich tmöglich bzw. zu aufwendig wäre.

> ADO.NET ist mit der DB-Ungebundenheit nicht schlecht.
genau daran habe ich auch gedacht, bin aber dann wieder was die DB-Kopplung angeht im Microsoft abhängigen Bereich.

Alternativ wäre ein intelligenter Query-Thread, die erst eine kleine Keytabelle vom Server abruft und dann die kompletten Datensätze anhand der Schlüssel in von/bis-Key Blöcken abruft.

**Bernhard Geyer**

Zitat von Phoenix:

Zitat von Bernhard Geyer:

ADO.NET ist mit der DB-Ungebundenheit nicht schlecht. Haben selbst sowas (um einigen Stufen einfacher gestrickt) selbst in unserer Anwendung.

Das ist leicht untertrieben

Zitat von Phoenix:

Ich habe letztens 'auf die Schnelle' eine Oracle-basierte .NET Anwendung auf die ADO.NET Interfaces gehoben, die ganzen Statements durch stored procedures ersetzt (also die SP's sozusagen als Schnittstelle zur beliebigen Datenbank definiert) und diese dann parametrisiert über die Interfaces angesprochen.

Hat mich knapp zwei Tage gekostet. Der größte Aufwand war es, das Datenbankschema auf MS SQL und Firebird zu hiefen und die SP's für diese Datenbanken zu schreiben. Und nach zwei Tagen konnte die Anwendung nicht nur Oracle sondern eben aus den SQL-Server und FB. So macht dann Datenbankentwicklung Spass

Dann werde ich deine Erfahrungen mal in einem

Thread vom Entwickler-Forum posten

**Bernhard Geyer**

Zitat von hermannhass:

Ich verzichte einerseits auf Fremdkomponenten, um nicht bei Updates (Delphiversion) trotz (erworbenen) Sourcecode mal auf dem Schlauch zu stehen, aber hauptsächlich aus Performancegründen.

Ist mir noch nicht passiert. Konnte bisher selbst D5-Kompos unter D2007 zum laufen bekommen.

Zitat von hermannhass:

Selbst das normale Delphi Treeview ist um einen 3 stelligen Faktor langsamer als ein Grid.

Da sag ich nur Virtueller Modus eines Tree's. 1 Mio. Datensätze sind damit kein Problem mehr.

Zitat von hermannhass:

Zum Thema zurück: sql-Injection...
soweit ich weiss, werden parametrisierte Befehle im Client substituiert und zum Server genauso geschickt, als wenn man die Parametersubstition direkt macht.

Eben nicht. Schau dir mal im MS SQL Tracer an was auf DB-Seite ankommt. Wenn die Statement noch Prepared sind kommot sowas der Art:

@Exec... <PreparedId>, <Parameterwert>,<Parameterwert>, ...

**alzaimar**

Was ich -ehrlich gesagt- nicht recht verstehe, ist das Bestreben, immer alles selbst machen zu wollen. Wenn man aus Lust und Tollerei programmiert, mag das noch einen gewissen Lerneffekt haben, aber wenn ich damit Geld verdienen will oder muss, dann benötige ich doch Jemanden, der mir die Arbeit abnimmt. Zeit ist Geld und eine kurze Überschlagsrechnung kommt zum Ergebnis, das 500 Euro für eine Komponente(nsammlung) lächerlich wenig ist, das es maximal 1-2 Manntagen entspricht.

Wenn ich ein Grid asynchron befüllen muss, weil es einfach zu viele Daten sind, dann habe ich einen Fehler im Programmdesign bzw. der GUI. Es gibt keinen einzigen Fall, in dem der Anwender mehr als -sagen wir- 1000 Datensätze wirklich benötigt. Wozu also einen Kopf um asynchrone Datenübertragung machen? Wenn der Anwender aber das nunmal partout so will, dann bekommt man das auch ohne serverseitigen Cursor hin, ein PK reicht allemal (und etwas 'Clustered Index' Äquivalentes).

Wenn(!) Du aber partout 100.000 Records anzeigen willst, ohne fetch-On-demand, dann versuch es mal (ieh! Fremdkomponente!) der VirtualTreeview von Mike Lischke. Ich glaube, die kann Daten auch in einem Gitter anzeigen. Aber wenn Du alles selbst basteln willst, dann nimm ein TDrawGrid / TStringGrid, ne TScrollBar und ein bisserl Gehirnschmalz. Aber wie gesagt, das ist der Versuch, Amateur-Access-Romantik mit einem SQL-Server zu fahren. Du haust Dir massig Load auf den Server, nur damit ein Anwender mal durchscrollen kann. Machen das 100 Anwender, benötigst Du sofort einen zweiten (oder dritten) Server.

Eine DB-Brücke ist schon was Feines, aber da greif ich doch einfach zu vorgefertigten Komponenten (Zeiteffizienz) z.B. DataAbstract von RemObjects. Es ist mir sowas von egal, ob die EXE nun 1 oder 10 MB groß ist. Weiterhin ist es i.A. irrelevant, ob eine DB-Abfrage nun in 10ms oder 30ms abgearbeitet ist, denn die Performancebremse #1 sitzt i.A. eh vor dem PC. Einerseits der Programmierer mit falschen Ansätzen und Algorithmen, und dann der Anwender mit dem stetigen Bestreben, etwas anderes zu tun, wie Kaffeetrinken, Zeitung lesen etc.

Das einzige Argument für das 'Selbermachen' wäre die Vermeidung von echten Programmfehlern. Wer sich z.B. bei ADO mal die SQL-Kommandos angeschaut hat, die generiert werden, wird sich nach kurzer Analyse entweder nach Alternativen umschauen oder sofort anfangen, soetwas selbst zu bauen. Insofern kann ich die Implementierung einer DB-Bridge nachvollziehen.

Last, but not least ein Wort zu Drittanbietern: Ich habe es aufgegeben, irgendwelche Freeware- oder Frickelkomponenten zu installieren, denn da ist es wirklich so, das dem Autor i.A. nach einigen Jahren die Luft ausgeht. Daher besorgt man sich nach reiflicher Überlegung ganz bestimmte Komponenten bei großen Anbietern (inkl. Sorucecode) und kann sicher sein, über die nächsten Jahre begleitet zu werden.

Im Gegenzug bekommt man unglaublich mächtige Komponenten, die dann auch mal dafür sorgen, einen zusätzlichen Auftrag zu bekommen. Ich hatte mir vor ca. 6 Jahrne(?) die DevExpress-Teile zugelegt und einen Prototypen zusammengeklickt: Der Auftrag wurde erteilt und ich hatte das Geld nach 2 Wochen 10x wieder drin.

Ich investiere lieber eine Woche mit einer Recherche über bereits fertige Lösungen, anstatt mich hinzusetzen, um sowas selbst zu basteln.

**Bernhard Geyer**

Zitat von alzaimar:

Weiterhin ist es i.A. irrelevant, ob eine DB-Abfrage nun in 10ms oder 30ms abgearbeitet ist,

Ist dann nicht mehr egal wenn es darum geht DB-Unabhängig Importe mit tausenden Datensätzen zu realisieren. Da ist es ein Unterschied ob es 5 oder 15 Stunden dauert ... Abe rmit dem "im Allgemeinen" ist es schon richtig. Für Prototyp oder erste Implementierung ist es wichtiger zu zeigen das es geht und wie die grobe Bedienung ist

Zitat von alzaimar:

Last, but not least ein Wort zu Drittanbietern: Ich habe es aufgegeben, irgendwelche Freeware- oder Frickelkomponenten zu installieren, denn da ist es wirklich so, das dem Autor i.A. nach einigen Jahren die Luft ausgeht. Daher besorgt man sich nach reiflicher Überlegung ganz bestimmte Komponenten bei großen Anbietern (inkl. Sorucecode) und kann sicher sein, über die nächsten Jahre begleitet zu werden.

Stimm ich soweit zu das man reiflich Überlegen sollte welche Komponente mann nimmt. Lieber ein Test zu viel als die Falsche Komponenten genommen.