|
Datenbank: mssql und mysql • Zugriff über: ado
Generelle Frag zu ADO
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 |
Re: Generelle Frag zu ADO
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? |
Re: Generelle Frag zu ADO
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. |
Re: Generelle Frag zu ADO
Zitat:
Was dann: Für MySQL würde ich von Core Labs die TDataset-Basierenten Komponenten verwenden. Zitat:
Zitat:
und nicht wirklich alles Hieb und Stichfest quotest würdest du bei einem Sicherheitsaudit mit Posaunen und Tropeten durchfallen. Zitat:
Zitat:
|
Re: Generelle Frag zu ADO
Zitat:
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 ;-) |
Re: Generelle Frag zu ADO
>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. |
Re: Generelle Frag zu ADO
Zitat:
Zitat:
Thread vom Entwickler-Forum posten :-) |
Re: Generelle Frag zu ADO
Zitat:
Zitat:
Zitat:
@Exec... <PreparedId>, <Parameterwert>,<Parameterwert>, ... |
Re: Generelle Frag zu ADO
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. :zwinker: 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. |
Re: Generelle Frag zu ADO
Zitat:
Zitat:
|
| Alle Zeitangaben in WEZ +1. Es ist jetzt 05:53 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz