Re: VB oder nicht VB?
- From: "Schmidt" <sss@xxxxxxxxx>
- Date: Sun, 12 Apr 2009 19:03:50 +0200
"Andreas Hachmann" <hanndi@xxxxxxxxxxxxxx> schrieb im Newsbeitrag
news:exzpxYGtJHA.4876@xxxxxxxxxxxxxxxxxxxxxxx
ich möchte aus reinen Gründen von Leidenschaft einenVB6 (wenn native kompiliert mit allen erweiterten Kompiler-
Player wie I-Tunes bauen.
Das Ganze in VB 6, (C kann ich nicht), mit einer
MySql Datenbank dahinter.
Wie schnell eine VB-App?
Optionen) erzeugt nahezu so schnellen Code wie VC6++ -
letztlich kommt ja dieselbe C-Kompiler-Technologie zum Einsatz
(die VB5 und VB6 native Kompilate werden halt anders als der
VB-PCode mittels C2.Exe erzeugt).
Aber das wäre nur dann relevant, falls Du Deine abzuspielenden
Sound-Daten noch (z.B. per eigenem Equalizer) manipulieren
möchtest vor der SoundAusgabe auf dem SoundDevice - oder
irgendwelche FFT-basierten Visualisierungen planst.
Der DB-Query relevante Teil läuft aber in von Dir hinsichtlich
der Performance nicht beeinflussbaren "externen Dlls" ab -
hier ist es für die Laufzeit der Abfrage nicht von Belang, ob
man die SQL-query nun von C++ - oder von VBScript aus absetzt.
Ist so eine Applikation mit VB zu realisieren, oder würde ichNein, egal welche Datenbank Du am Ende einsetzt - Abfragen
bei Eingabe eines Suchtextes zu lang warten müssen?
gegen eine Liste aus nur 30000 Vergleichs-Einträgen sollten
heutzutage eigentlich unter der "Unmuts-Schwelle" von ca.
150msec liegen (die bei einer "getippten LiveSuche+Aktualisierung"
so in etwa in der genannten Größenordnung gesetzt werden sollte).
(AutoFilter Funktion direkt bei der Eingabe jedes Buchstaben)Hier ist dann wieder eher die Geschwindigkeit der Kombination
Datensätzen werden ca 30000 Tracks sein.
aus Datenzugriffs-Schicht und DB-Engine entscheidend, nicht
so sehr, ob die VB6-Anwendung nun zu Native-Code oder zu
PCode kompiliert wurde -
also letztlich die Kette bis "kurz vorm GUI-Refresh":
ADO-Klassen in VB6 -> OleDB-JET-Driver -> mdb-File
ADO-Klassen in VB6 -> OleDB-MySQL-Driver -> MySQL-DB
dhSQLite-Klassen in VB6 -> sqlite36_engine.dll -> SQLite-DBFile
Bauen oder besser die Finger davon lassen?Zu letzterem Eintrag in der Liste (SQLite-VB6-Wrapper) bin ich
mir bzgl. der Performance, die über die beschriebene Aufrufkette
letztlich in der VB6-App ankommt jedenfalls absolut sicher, dass
es am DB-Query-Teil nicht haken wird ;-) Das ist gleichzeitig auch
die Variante, die den geringsten Deployment-Umfang hat (sind
dann im Prinzip nur 3 Dlls, die neben "der Exe" liegen).
Empfehlenswert wäre vielleicht noch ein schnelles Grid für
virtuellen Modus (das aus dem resultierenden Recordset
dann nur die aktuell sichtbaren Zeilen anzeigt bzw. "rendert"),
oder eine entspr. Top-Clausel im SQL-Select, die die gefundenen
Treffer dann vom Umfang her reduziert, so dass man auch
ohne "virtuelles Grid" nicht allzuviel zu rendern, bzw. als User
dann "zu scrollen" hat.
Der virtuelle Modus geht entweder mit dem VB6-Datagrid
oder mit einem der kommerziellen FlexGrids von
ComponentOne (die mit VB6 kommenden FlexGrids unterstützen
den Virtual-Mode jedoch nicht) - oder man schreibt sich
sein "virtuelles Listencontrol" ohnehin selbst, da man dann
(gerade beim Thema Multimedia) so ein paar mehr Freiheits-
grade gewinnt.
Zum aktuellen VB6-SQLite-Wrapper (Dieters Link klappt bei mir
leider nicht) kann man sich auch hier belesen:
http://www.thecommon.net/2.html
bzw. direkt downloaden:
www.datenhaus.de/Downloads/dhRichClient3.zip
www.datenhaus.de/Downloads/dhRichClient3-Demo.zip
Und weil Dieter die nested transactions erwähnt hat, die
sind inzwischen drin in der offiziellen sqlite-engine und
werden von meinem Wrapper auch unterstützt, ebenso
wie Like-queries, die von einen auf der Text-Column
definierten Index Gebrauch machen können, solange
man den Titel-Anfang:
.... Where SongTitleCol Like 'SomePart%'
und nicht:
.... Where SongTitleCol Like '%SomePart%'
"irgendwas mitten im Titel" abfragt.
Im letzteren Falle wäre dann ein FullTable-Scan nötig.
Aber auch der sollte gegen eine Datenbasis von nur
30000 Records ausreichend schnell laufen.
Und wenn schon FullTable-Scan, dann kann man auch
vom im Wrapper eingebauten RatCliff-Algo Gebrauch
machen - der ermöglicht unscharfe Suche, da er nur
eine Wort-Ähnlichkeit berechnet:
Select *, Ratcliff(SongTitleCol, 'SomePart') As RcVal
From SongsTbl
Order By RcVal Desc
Limit 50
gäbe dann eine entsprechend nach Ähnlichkeit (absteigend)
sortierte Liste mit den besten (maximal) 50 Treffern aus.
Hab den Fulltable-Scan mittels Ratcliff gerade nochmal getestet
gegen eine Tabelle mit 30000 Records (die SuchSpalte in
der DB enthielt jeweils 40 Zeichen lange Texte... das Ganze
braucht dann so zwischen 130 und 240msec - je nachdem
wie lang der aktuell unscharf zu suchende String war (die
kürzeren Such-Zeiten dann bei entsprechend kürzerem
Suchstring).
Aber normalerweise hört man bei dem Ansatz ja nach bereits
4-6 Zeichen auf zu tippen, da das gewünschte Ergebnis dann
bereits irgendwo in den "Top 10" auftaucht. Liegt also selbst
bei dieser aufwändigen Suchvariante noch so in etwa innerhalb
des noch nicht als "zäh" empfundenen Verzögerungs-Bereichs.
Der FullTable-Scan mittels Like '%SomePart%' (also Suche
irgendwo mitten im Titel-Text) ist nicht so aufwändig
wie der Ratcliff und dauert so zwischen 20 und 50msec.
Index-Unterstützung bei der Suche mittels Like 'SomePart%'
(also wenn man zumindest den Beginn des Titels richtig schreibt)
macht dann natürlich "blink" (und dauert so ca. 0.6 - 1msec).
Olaf
.
- References:
- VB oder nicht VB?
- From: Andreas Hachmann
- VB oder nicht VB?
- Prev by Date: Re: Combobox füllen
- Next by Date: Datumsformat in gespeicherten Views einer Oracle-DB
- Previous by thread: VB oder nicht VB?
- Next by thread: Re: VB oder nicht VB?
- Index(es):
Relevant Pages
|
