![]() |
Re: Generelle Frag zu ADO
Zitat:
Aber dann gibt es bestimmt wieder Ausnahmen, sodaß man im Sonderfall nun doch irgendwann auf DirectSQL zurückgreifen wird. P.S.: Ein Supertool (für MSSQL), um 100.000 Datensätze in ein paar Sekunden zu importieren, ist immer noch BCP, das vollständig kommandozeilenorientiert gesteuert werden kann. Die FMT-Datei kann man sich anhand der zu importierenden Felder schnell selbst basteln, die zu importierende Datei ist auch -wupps- gebastelt. Dann BCP.EXE anwerfen und es reicht noch nichtmal für den Kaffee. Vorteil: Wenn Dir der Import als Tagesjob zugeteilt wurde, hast Du um 09:00 schon Feierabend :mrgreen: |
Re: Generelle Frag zu ADO
Zitat:
|
Re: Generelle Frag zu ADO
Erstmal Danke für die Diskussion.
Was das selbermachen angeht, gibt es natürlich Grenzen, sonst könnte man gleich wieder Maschinencode programmieren. Ich habe früher viel in fertige Komponenten investiert, nur stösst man dort auch auf Grenzen, was Performence und Updates in höhere Delphi/Codegear Versionen, wenn das Produkt nicht parallel mitgepflegt wird. Natürlich ist es quatsch bzw. i.d.R. Designfehler, tausende von Daten abzurufen und darzustellen, wenn nur ein Teil sichtbar und nur ein Bruchteil benötigt wird. Nur zeigt nun mal die Erfahrung(ich entwickle Software seit 20 Jahren), dass je mächtiger und vielfältiger ein Tool, eine Komponente oder Entwicklungsumgebung ist, die Entwichklungszeit zwar drastisch abnimmt,man immer schneller 90 oder 95% seines gewünschten "outputs" erreicht, aber für die letzten 5% an optischen/Handlingtechnischen Output immer mehr Zeit braucht. Um so mehr individuelle Details man aus optischen oder handlinggründen einarbeiten will, um so mehr "Frickelei" ist notwendig. Um 100% seines oder des Kunden gewünschten Outputs zu haben, ist dann eine Bottom-up Programmierung im Endeffekt sinnvoller. Wie gesagt, ist meine Meinung und bezieht sich auf alle Bereiche, nicht nur Delphi sondern auch z.B. Webdesign. Zu den Datenbanken zurück. Natürlich ist heutzutage eine Speicherplatzoptimierung zugunsten der Zeiteffizienz absolut zweitranig. Meine Hauptfrage basierte auch eher nach einer trivialen mssql und mysql Kopplung, ohne viel Schnickschnack. Meine Serverabhängige sql-Syntax bilde ich selber, um möglichst serverunabhängig zu sein. Die Zeos sind mir eindeutig zu langsam,wenn ich z.B. viele Daten zum Listendruck benötige. notfalls bleibe ich bei den ADO, wober sich sowieso nur den Dataset benutze. |
Re: Generelle Frag zu ADO
Zitat:
|
Re: Generelle Frag zu ADO
Ich habe vorgestern die neuesten ZEOS (ZEOSDBO-6.6.1-beta) runtergeladen und ein wenig gestestet.
Gestestet habe ich nur mit mySQL und MS-Server, und auch nur einen kleinen Read-Test per Select, das es mir auf den Datenvolumentransfer ankam. Server Tabelle mit mit 7000 Zeilen und 50 Spalten, Client-Server Komplettes Open und Transfer auf Client: MSSERVER: ADA ca. 1200ms ZEOS: ca. 2600ms (also mehr als doppelt lange) MYSQL: ADA ca. 950ms ZEOS: ca. 1300ms das ganze mehrmals reproduzierbar Komplexere Tests mit Inserts hatte ich keine Lust mehr, da bei einer meiner Applicationen das Abrufen von grossen Datenmengen im Vordergrund steht... |
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:04 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