DLL voor ADO & tekstbestanden ontwerpen

[pkouwer]

Hi,

Ik wil middels een DLL een schil leggen tussen mijn applicatie en de database. In de toekomst wil ik deze DLL kunnen vervangen omdat er dan bv een andere database of zelfs een tekstbestand gebruikt gaat worden. Nu is mijn vraag: als ik een database gebruik krijg ik een recordset terug, als ik een tekstbestand gebruik ontvang ik alleen maar tekst.

Hoe kan ik dit opvangen zonder dat ik mijn applicatie zelf hoef aan te passen ?

[Gerco]

Je zal dan zelf een RecordSet klasse moeten schrijven en je applicatie daarvan gebruik laten maken. Op die manier kan je applicatie het verschil niet zien tussen een RecordSet uit een ADO database en een RecordSet uit een txtbestand. Aangezien ze allebei je eigen recordset klasse gebruiken.

Alleen moet je je applicatie dan natuurlijk wel ALLEEN gebruik laten maken van je eigen RecordSet.

[Verwijderd]

zet je text om in een database .. . simpel. .

[pkouwer]

Op woensdag 17 juli 2002 09:04 schreef Skizmo het volgende:
zet je text om in een database .. . simpel. .

daar draait het nou net om dat dat niet de bedoeling is.

Heeft te maken met de performance.

[Verwijderd]

Er is een .txt rowreader driver voor ADO, die wordt meegeinstalleerd bij MDAC, de ado components

Echter, die kan CSV rows lezen en als je die wilt lezen dan zou ik toch voor de database gaan zoals hierboven is gezegd, want dat is sneller dan uit een textfile lezen.

Je opent zo'n recordset vanuit een .csv of .txt file als volgt: (VB6)

code:

cnADO.Open "Driver={Microsoft Text Driver (*.txt; *.csv)};dbq=C:\...\;Extensions=asc,csv,tab,txt;"
rsADO.Open "SELECT * FROM " & sFilename, cnADO, adOpenStatic, adLockReadOnly, adCmdUnknown

waarbij sFilename.... de filename is!

De 1e regel moet de veldnamen bevatten in de .txt file.

[pkouwer]

een database met 600.000 records doorzoeken sneller dan een tekstbestand ? hmmm

Ik heb zo m'n twijfels.

[Gerco]

Op woensdag 17 juli 2002 09:33 schreef pkouwer het volgende:
een database met 600.000 records doorzoeken sneller dan een tekstbestand ? hmmm

Je bedoelt hopelijk niet dat je denkt dat de database langzamer is dan een txt file he?

Een database is geindexeerd en heeft meestal iets wat op vaste recordgroottes lijkt. Op die manier is een willekeurig record meestal in O(log n) te bereiken (binaire zoekboom, geloof ik, die O's zeggen me niet zo heel veel). En in een tekstbestand is dat O(n) (je moet in het ergste geval het hele bestand doorlopen en de snelheid daarvan is direct afhankelijk van het aantal records wat erin zit)

[pkouwer]

random leesactie

[Verwijderd]

Op woensdag 17 juli 2002 09:33 schreef pkouwer het volgende:
een database met 600.000 records doorzoeken sneller dan een tekstbestand ? hmmm

Ik heb zo m'n twijfels.

[pkouwer]

tis toch echt waar, aan den lijve ondervonden

[Verwijderd]

Volgens mij heb je gelijk...
Het doorlopen van een 600.000 records in een database zal waarschijnlijk langzamer gaan dan 600.000 regels in een tekstbestand.

[pkouwer]

zeker als het een Access db-tje is ...

[Verwijderd]

600.000 rows met een indexed key. hoeveel lookups moet men dan doen in het ergste geval?

600.000 rows in een textfile, hoeveel lookups moet men dan doen in het ergste geval?

Juist.

[Verwijderd]

600.000 rows met een indexed key. hoeveel lookups moet men dan doen in het ergste geval?

20, gemiddeld 20

600.000 rows in een textfile, hoeveel lookups moet men dan doen in het ergste geval?

600.000, gemiddeld 300.000

Maar ik blijf erbij, als je geen indexed key gebruikt, is waarschijnlijk de database langzamer (oke, en nu stop ik met die sarcastische opmerkingen )

[Verwijderd]

Op woensdag 17 juli 2002 10:32 schreef Debbus het volgende:
[..]
20, gemiddeld 20
[..]
600.000, gemiddeld 300.000
Maar ik blijf erbij, als je geen indexed key gebruikt, is waarschijnlijk de database langzamer (oke, en nu stop ik met die sarcastische opmerkingen )

Noem 1 database die geen indices creeert over keys...

[Creepy]

Op woensdag 17 juli 2002 10:30 schreef Otis het volgende:
600.000 rows met een indexed key. hoeveel lookups moet men dan doen in het ergste geval?

600.000 rows in een textfile, hoeveel lookups moet men dan doen in het ergste geval?

Juist.

En nu gewoon alles linear inlezen.
Wat is sneller???

select * from tabel of alle regels van een tekstbestand inlezen zonder alle DB overhead.

Het ligt natuurlijk aan de specifieke situatie of een DB sneller is dan een tekstfile of andersom.

[Janoz]

Op woensdag 17 juli 2002 09:37 schreef Gerco het volgende:
(binaire zoekboom, geloof ik, die O's zeggen me niet zo heel veel).

offtopic:
Eigenlijk is het heel simpel. Ordes geven aan hoe de lengte (of het geheugen gebruik) afhangt van de hoeveelheid data. Een O(N) algoritme kan bij dezelfde hoeveelheid data best sneller zijn dan een O(log N). Wat je juist met die ordes aan geeft is dat waneer de hoeveelheid data 2x zo groot wordt, het O(N) algoritme er ook 2x zo lang over doet (lineair) terwijl het O(log N) er maar 1 stapje extra over doet.

Op woensdag 17 juli 2002 12:16 schreef Creepy het volgende:

[..]

En nu gewoon alles linear inlezen.
Wat is sneller???

select * from tabel of alle regels van een tekstbestand inlezen zonder alle DB overhead.

Het ligt natuurlijk aan de specifieke situatie of een DB sneller is dan een tekstfile of andersom.

Een booem is ook heel makkelijk in O(n) in infix volgorde uit te lezen.. Mischien gaat het opleppelen van die records wel iets langzamer dan het inlezen van net zoveel regels, maar dan speel je vals, aangezien de DB de data al netjes aanleverd (wat behoorlijk efficient geimplementeerd is), en de tekstlezer al die regels nog moet 'parsen'.. Echt veel verschil zal er uiteindelijk niet in gaan zitten hoor...

[Verwijderd]

Op woensdag 17 juli 2002 12:16 schreef Creepy het volgende:
[..]
En nu gewoon alles linear inlezen.
Wat is sneller???

Mja, alles opnieuw intikken is nog trager, kom op zeg.

Hij heeft het over zoeken. Daar zijn databases voor: het opslaan van de data in een zodanig formaat dat zoeken veel sneller is dan op een andere, ongeordende manier, ZOALS een textfile.

select * from tabel of alle regels van een tekstbestand inlezen zonder alle DB overhead.
Het ligt natuurlijk aan de specifieke situatie of een DB sneller is dan een tekstfile of andersom.

Nee. Een database is in alle gevallen sneller, dit omdat er extra gegevens beschikbaar zijn die activiteiten op de data versnellen, zaken die je bij een textfile niet hebt. (en een textfile van 600.000 regels is niet mals, daar operaties op doen kost ook tijd, bv een regel toevoegen in het midden.;))

[Creepy]

Op woensdag 17 juli 2002 12:36 schreef Otis het volgende:

[..]

Mja, alles opnieuw intikken is nog trager, kom op zeg.

Hij heeft het over zoeken. Daar zijn databases voor: het opslaan van de data in een zodanig formaat dat zoeken veel sneller is dan op een andere, ongeordende manier, ZOALS een textfile.
[..]

Nee. Een database is in alle gevallen sneller, dit omdat er extra gegevens beschikbaar zijn die activiteiten op de data versnellen, zaken die je bij een textfile niet hebt. (en een textfile van 600.000 regels is niet mals, daar operaties op doen kost ook tijd, bv een regel toevoegen in het midden.;))

[nog ff snel offtopic dan]
600.000 namen in 1 tekstfile.. 1 naam per regel. inlezen.. klaar..

en dan een select * from namen en alle namen binnen halen.

Ik heb er erg mijn twijfels over dat de DB (en dan zeker een access db) sneller zal zijn dan 600.000 regels inlezen..

Het blijft gewoon sterk afhankelijk van de situatie. Als je zelf eerst nog de regel moet gaan parsen, heb je weer extra overhead, die een DB voor je afvangt, en dan waarschijnlijk weer wel sneller zal zijn.
[/offtopic]

Maaruh.. volgens mij is een goede oplossing al gegeven. Defineer zelf een RecordSet klasse, die je gebruikt voor je DLL en je APP, en in de DLL zet je die klasse weer om naar het goede formaat. DLL vervangen kan dan zonder problemen.

[Verwijderd]

Op woensdag 17 juli 2002 12:54 schreef Creepy het volgende:
[..]
[nog ff snel offtopic dan]
600.000 namen in 1 tekstfile.. 1 naam per regel. inlezen.. klaar..
en dan een select * from namen en alle namen binnen halen.
Ik heb er erg mijn twijfels over dat de DB (en dan zeker een access db) sneller zal zijn dan 600.000 regels inlezen..

Maar, waarom lees je ze in? Voor de gein? Nee, om er in te zoeken, zoals hier is gesteld. Dat zoeken gaat in een db wel even wat sneller dan in een tekstfile. Ook bij access.

Het blijft gewoon sterk afhankelijk van de situatie. Als je zelf eerst nog de regel moet gaan parsen, heb je weer extra overhead, die een DB voor je afvangt, en dan waarschijnlijk weer wel sneller zal zijn.

Hoe wil je anders de data gebruiken, die je uit de textfile leest, ZONDER te parsen?

/me schudt zn hoofd.

[Gerco]

Op woensdag 17 juli 2002 12:54 schreef Creepy het volgende:
Ik heb er erg mijn twijfels over dat de DB (en dan zeker een access db) sneller zal zijn dan 600.000 regels inlezen..

Daar zou je best weleens gelijk in kunnen hebben, maar je moet ook je data niet altijd sequentieel inlezen... Ik neem aan dat als je een tekstbestand van 600k namen hebt, je niet die 600k namen altijd allemaal nodig hebt. In een realistische situatie is een DB bijna altijd sneller... alleen in dat ene onwaarschijnlijke geval van alles sequentieel uitlezen misschien niet.

En dan heb ik het nog niet eens over iets veranderen in je file...

[pkouwer]

ok,ok. Stel ik de volgende vraag. Het lezen/schrijven van de database met genoemde omvang en type is veeeeeel te langzaam. Welke alternatieven heb ik dan? MySQL is misschien een optie....

[Creepy]

Op woensdag 17 juli 2002 13:28 schreef Gerco het volgende:

[..]

Daar zou je best weleens gelijk in kunnen hebben, maar je moet ook je data niet altijd sequentieel inlezen... Ik neem aan dat als je een tekstbestand van 600k namen hebt, je niet die 600k namen altijd allemaal nodig hebt. In een realistische situatie is een DB bijna altijd sneller... alleen in dat ene onwaarschijnlijke geval van alles sequentieel uitlezen misschien niet.

En dan heb ik het nog niet eens over iets veranderen in je file...

Ik ook niet

Maar ik wilde de opmerking "Een DB is altijd sneller" ff ontkrachten, aangezien die niet waar is.

Inlezen met je huidige DB is dus langzaam?? Weet je zeker dat dat echt ligt aan access, en niet aan je datastructuur, indexen, de manier van records ophalen e.d.?

Als je dat zeker weet zou je eens kunnen kijken naar andere DB's ja.

Maar welke DB "sneller" is dan een andere is ok weer afhankelijk van een aantal factoren (gebruikte index, tabel type, filesystem e.d.)

[Creepy]

Op woensdag 17 juli 2002 13:28 schreef Otis het volgende:

[..]

Maar, waarom lees je ze in? Voor de gein? Nee, om er in te zoeken, zoals hier is gesteld. Dat zoeken gaat in een db wel even wat sneller dan in een tekstfile. Ook bij access.
[..]

Hoe wil je anders de data gebruiken, die je uit de textfile leest, ZONDER te parsen?

/me schudt zn hoofd.

Nee. Een database is in alle gevallen sneller, dit omdat er extra gegevens beschikbaar zijn die activiteiten op de data versnellen, zaken die je bij een textfile niet hebt.

Het ging mij er om dat een database niet in alle gevallen sneller is. Dat een DB sneller is als je in je data gaat zoeken, muteren e.d. snap ik ook wel. Als je echter alleen domweg je data ophaalt, hoeft dit echter niet het geval te zijn.

En ja.. zelfs dat laatste gebeurt (ophalen wegschrijven van settings, taal afhankelijke delen in je programma)

[pkouwer]

got it, als ik nu alle db-handelingen in een dll stop, kan ik het idd makkelijker vervangen. Is dit ook sneller dan deze db-handelingen in de applicatie zelf stoppen ??

[Janoz]

Op woensdag 17 juli 2002 13:45 schreef Creepy het volgende:

En ja.. zelfs dat laatste gebeurt (ophalen wegschrijven van settings, taal afhankelijke delen in je programma)

Om voor het wegschrijven van settings een compleet DB component op te nemen is natuurlijk overkill, maar ik neem niet aan dat je setting bestanden van 600K hebt, aangezien het dan waarschijnlijk een stuk minder overkill gaat worden .

[Janoz]

Op woensdag 17 juli 2002 13:48 schreef pkouwer het volgende:
got it, als ik nu alle db-handelingen in een dll stop, kan ik het idd makkelijker vervangen. Is dit ook sneller dan deze db-handelingen in de applicatie zelf stoppen ??

Is een beetje afhankelijk op welk niveau je je dll wilt hebben. D'r zijn 2 uitersten.
1 Je kunt die laag heel dicht bij de DB leggen. Dan zul je SQL commando's naar je dll moeten sturen die deze op een DB uitvoerd.
2 JE kunt die laag heel dicht bij je applicatie leggen, dan heb je bijvoorbeeld een methode haalKlantGegevens(int klantID). Dit wordt dan in je DLL op 1 of andere manier uit je data getrokken en in een leuk jasje gestopt en terug gegeven.

Hoe dichter je dat niveau bij een uiterste legt hoe minder flexibel het aan die kant wordt. Bij Optie 1 kun je de DLL bijna overal gebruiken, maar beperk je de keuzes voor je datasource (niet alleen of je DB of textfile gebruikt, maar ook vanwege verschillende SQL dialecten, denk aan TOP en LIMIT)

Optie 2 geeft je een enorme vrijheid in de keuze voor je dataopslag, maar zorgt ervoor dat je DLL alleen bij dat specifieke programma te gebruiken is.

Een middenweg is om zelf een intermediate query language te maken. Gewoon een heel simpele syntax die je in je DLL omzet naar de juiste SQL (top en subqueries voor mssql en limit en geen subqueries voor mysql bv) of die er voor zorgt dat de juiste gegevens uit je tekstbestand gelezen worden. Je kunt voor die intermediate taal bijvoorbeeld een subset van SQL gebruiken zodat de vertaalslag bijna 1 op 1 is.

[Gerco]

Op woensdag 17 juli 2002 13:48 schreef pkouwer het volgende:
got it, als ik nu alle db-handelingen in een dll stop, kan ik het idd makkelijker vervangen. Is dit ook sneller dan deze db-handelingen in de applicatie zelf stoppen ??

Nee, het is niet sneller, het is zelfs een paar microsecondes langzamer, aangezien er een extra function call moet plaatsvinden.

In plaats van App -> DB, doe je nu App -> DLL -> DB, en dat is natuurlijk een HEEL KLEIN beetje langzamer...

Maar niet genoeg om te zorgen dat je het merkt.

Zitten we eigenlijk wel indexes op je access DB? en hoe selecteer je je data? Access moet toch wel kunnen omgaan met 600k records... alhoewel dit behoorlijk veel is voor Access

50k records doet 'ie in ieder geval zonder enig probleem, meer heb ik nog niet geprobeerd.

[Creepy]

Op woensdag 17 juli 2002 13:49 schreef Janoz het volgende:

[..]

Om voor het wegschrijven van settings een compleet DB component op te nemen is natuurlijk overkill, maar ik neem niet aan dat je setting bestanden van 600K hebt, aangezien het dan waarschijnlijk een stuk minder overkill gaat worden .

Whehe..

Heb een keer een klant gehad, die bij hoog en laag bleef beweren dat we voor het opslaan van 10 regels tekst (ophalen bij start van het programma, en wegschrijven aan het eind )een DB sneller is dan een textfile.. dus vandaar dat ik dat zei..

Nou weet ik ook wel dat het nivo van jou en Otis stukken hoger is dan dat hehe.. maar toch.. kon het niet laten

[Verwijderd]

Op woensdag 17 juli 2002 13:34 schreef pkouwer het volgende:
ok,ok. Stel ik de volgende vraag. Het lezen/schrijven van de database met genoemde omvang en type is veeeeeel te langzaam. Welke alternatieven heb ik dan? MySQL is misschien een optie....

MSDE, is de desktop versie van SQLServer, en is te gebruiken alsje een office license of VB license hebt.

[Verwijderd]

Op woensdag 17 juli 2002 13:40 schreef Creepy het volgende:
[..]
Ik ook niet
Maar ik wilde de opmerking "Een DB is altijd sneller" ff ontkrachten, aangezien die niet waar is.

Stel maar een gedachtenexperiment op, dus een situatie waarin je data MOET lezen. Niet 'om het lezen', want dat is niet een realistische situatie, daar een fread(); van een file altijd rapper is, maar je hebt aan de ingelezen data pas iets als je er semantische waarde aan kunt verbinden, bv door het op te delen in regels.

Ik geef je op een briefje dat een database _ALTIJD_ sneller is dan een tekstfile. Dat concluderen is ook niet zo moeilijk: de tekstfile heeft _NIETS_ aan informatie dat de lezer helpt, de database wel degelijk.

Inlezen met je huidige DB is dus langzaam?? Weet je zeker dat dat echt ligt aan access, en niet aan je datastructuur, indexen, de manier van records ophalen e.d.?

*pssst*, een database maakt ook gebruik van een file met daarin een eigen bestandssysteem.

[Verwijderd]

Op woensdag 17 juli 2002 13:45 schreef Creepy het volgende:
Het ging mij er om dat een database niet in alle gevallen sneller is. Dat een DB sneller is als je in je data gaat zoeken, muteren e.d. snap ik ook wel. Als je echter alleen domweg je data ophaalt, hoeft dit echter niet het geval te zijn.
En ja.. zelfs dat laatste gebeurt (ophalen wegschrijven van settings, taal afhankelijke delen in je programma)

Lariekoek. Zelfs plaatjes uit een database halen ipv die van schijf lezen is sneller in zeer veel gevallen, daar de data in een database veel sneller accessable is dan via een filesystem dat filefragments all over the place heeft, een database' filesystem heeft dat niet.

[Verwijderd]

Op woensdag 17 juli 2002 14:01 schreef Creepy het volgende:
Heb een keer een klant gehad, die bij hoog en laag bleef beweren dat we voor het opslaan van 10 regels tekst (ophalen bij start van het programma, en wegschrijven aan het eind )een DB sneller is dan een textfile.. dus vandaar dat ik dat zei..

Met een open database connectie en een database die caching gebruikt is de database ook bij 10 regels tekst sneller, daar het filesystem gericht is op het snel betrekken van data dmv een snelle index. Nu zul jehet verschil bij 10 regels tekst niet zien, maar 10.000 keer 10 regels tekst levert wel degelijk een zichtbaar verschil op. Staar je niet blind op OS filesystem snelheid.