[Database] Zoeken in veel records

[Dutch_guy]

Ik heb onlangs met VB6 en Access 2000 een programmaatje gemaakt waarbij men kan zoeken op klantnummer, waarna men de NAW gegevens van die klant ziet en eventueel kan wijzigen.
Tevens kan men met checkboxes aangeven wat men wil bestellen.

Dat werkte prima, totdat..........
mij werd verteld dat er in 1.5 miljoen records gezocht moest worden. Dat word niks met Access.

Nu heb ik de beschikking over Microsoft Visual Foxpro, die hier wel mee overweg kan.

Aangezien ik nog geen programmeerervaring heb met Foxpro, wil ik de frontend met VB6 maken.

Waar moet ik op letten bij het ontwerpen, om het geheel nog snel te laten lopen?

Welke connectie werkt het snelst? ODBC, ADO, DAO ???
Ik had wel gezien dat sommige connecties niet met indexes kunnen werken.

Iemand tips ?

[whoami]

De goeie indexen leggen, zal een van de belangrijkste criteria zijn.

[Dutch_guy]

Klopt het dat dit alleen kan met DAO ?

Wat is momenteel eigenlijk de best te gebruiken connectie ?
Ik ben het spoor een beetje bijster.

[cameodski]

Dutch_guy schreef op 11 oktober 2002 @ 10:32:
Ik had wel gezien dat sommige connecties niet met indexes kunnen werken.

Wat bedoel je?
De connectie bepaalt niet of er en zo ja welke indexen er gebruikt worden.
Je stuurt een query richting database en die gaat zelf op zoek naar de beste/snelste manier om deze query uit te voeren.

[Verwijderd]

Hmm. Ik ga je toch aanraden om van access af te stappen en de overstap naar MySql of PostgreSql te maken, deze paketten gaan beter om met grote hoeveelheden records. Bovendien moet je indexes maken van maken en desnoods ook weer een index van een index.

[whoami]

Verwijderd schreef op 11 oktober 2002 @ 11:14:
Hmm. Ik ga je toch aanraden om van access af te stappen en de overstap naar MySql of PostgreSql te maken, deze paketten gaan beter om met grote hoeveelheden records. Bovendien moet je indexes maken van maken en desnoods ook weer een index van een index.

Dutch_guy vermeld al in z'n openingspost dat hij van access moet afstappen om die reden en dat hij naar Foxpro overstapt.

cameodski schreef op 11 oktober 2002 @ 10:43:
[...]

Wat bedoel je?
De connectie bepaalt niet of er en zo ja welke indexen er gebruikt worden.
Je stuurt een query richting database en die gaat zelf op zoek naar de beste/snelste manier om deze query uit te voeren.

Inderdaad, ik zie niet echt een verband tussen de connectie-methode en het al of niet kunnen gebruik van indexen.
Ik denk dat ADO de beste connectie-methode zal zijn.

[Dutch_guy]

Misschien heb ik het verkeerd begrepen. Ik had gelezen dat met de Data control van Visual Basic het niet mogelijk is om indexen te gebruiken.

[Uiligheid]

Dat kon inderdaad nog wel eens kloppen..
Tijdens een projectje wat ik een tijdje geleden heb gedaan, heb ik ondervonden dat het snelst gewoon een ODBC-koppeling met keiharde SQL-request was.

Maar als je je applicatie hebt gebouwd, dan neem ik toch aan dat je hem dermate flexibel hebt, dat het niet een crime is om er een andere db onder te zetten (n-thier)

[cameodski]

Ik weet niet wat die Data control precies doet, maar ik hoop niet dat ie gewoon de hele tabel gaat ophalen en vervolgens zelf gaat zitten filteren, want dan heb je dus echt een probleem. In dat geval zou ik die control toch maar niet gebruiken.
Als het wat anders is, weet ik niet wat er bedoeld wordt en hoop ik maar dat je het verkeerd begrepen heb.

[Dutch_guy]

Inderdaad, dat is wat die Data Control doet. Niet leuk met 1.5 miljoen records.
Daar moet ik dus vanaf, vandaar dat ik alles opnieuw moet maken.

[Verwijderd]

Ik gebruik altijd een connectie die ik definieer in de code, dus geen ODBC en zeker geen Data Control. Verder vindt ik ADO de snelste oplossing. Als iemand interesse heeft wil ik die code wel ff posten.

Trouwens, als ik mij niet vergis geef je op de DATABASE bepaalde velden een index en heeft dat dus eigenlijk nix te maken met je Data Control zoals hierboven genoemd wordt.

[Verwijderd]

'k heb laatst ook zoiets gemaakt, mijn oplossing was: splits het klantenbestand in 9 tabellen, waarbij het eerste cijfer in het klantnummer bepaald in welke tabel het nummer terecht komt. Bij het zoeken lees je het eerste cijfer uit, opent de bijbehorende tabel, etc... Scheelt dus enorm in snelheid

<edit> of je splitst op postcode / laatste cijfer / etc... </edit>

[Dutch_guy]

Verwijderd schreef op 11 oktober 2002 @ 12:19:
'k heb laatst ook zoiets gemaakt, mijn oplossing was: splits het klantenbestand in 9 tabellen, waarbij het eerste cijfer in het klantnummer bepaald in welke tabel het nummer terecht komt. Bij het zoeken lees je het eerste cijfer uit, opent de bijbehorende tabel, etc... Scheelt dus enorm in snelheid

<edit> of je splitst op postcode / laatste cijfer / etc... </edit>

Dat klinkt goed, ik ga dat proberen.

[cameodski]

Verwijderd schreef op 11 oktober 2002 @ 12:19:
'k heb laatst ook zoiets gemaakt, mijn oplossing was: splits het klantenbestand in 9 tabellen, waarbij het eerste cijfer in het klantnummer bepaald in welke tabel het nummer terecht komt. Bij het zoeken lees je het eerste cijfer uit, opent de bijbehorende tabel, etc... Scheelt dus enorm in snelheid

<edit> of je splitst op postcode / laatste cijfer / etc... </edit>

Dat is dus iets waar je als het even kan niet eens over na moet denken. Hoe gaat je het bijvoorbeeld aanpakken met foreign keys.
En waar denk je dat indexen voor uit zijn gevonden? Inderdaad, juist voor dit soort zaken.
In dit geval werkt het misschien wel aardig, omdat je een klantnummer hebt en op basis daarvan gaat zoeken, maar hoe wil je bijvoorbeeld zoeken op naam? Moet je opeens in 9 tabellen gaan zoeken.
En hoe wil je bijvoorbeeld voorkomen dat een klant met verschillende klantnummers voorkomt. Als het in één tabel staat, kun je een unique constraint gebruiken, maar hoe moet dat met 9 tabellen.
Kortom: opsplitsen in meerdere tabellen alleen maar doen als je echt heel erg omhoog zit en anders helemaal nooit aan beginnen.

[Verwijderd]

Dat is lang geleden dat ik iemand gehoord heb over foxpro.

Als ik jou was zou ik fox links liggen en naar Sql Server overstappen. Fox is leuk, maar ook daar zijn grote aantal records niet echt fijn.
Daarnaast is de support van microsoft voor fox niet erg groot

[whoami]

Verwijderd schreef op 11 oktober 2002 @ 12:19:
'k heb laatst ook zoiets gemaakt, mijn oplossing was: splits het klantenbestand in 9 tabellen, waarbij het eerste cijfer in het klantnummer bepaald in welke tabel het nummer terecht komt. Bij het zoeken lees je het eerste cijfer uit, opent de bijbehorende tabel, etc... Scheelt dus enorm in snelheid

<edit> of je splitst op postcode / laatste cijfer / etc... </edit>

Dit is nou eens wat men noemt een slecht data-ontwerp.
Alle klanten horen gewoon thuis in 1 tabel, je hoeft geen negen klantentabellen te hebben. Wat brengt dit allemaal niet met zich mee qua overhead? Hoe lang duurt het eer de gegevens inconsistent zijn?
Al heb je een miljoen records in een tabel, dan nog kan het ophalen van gegevens zeer snel zijn als je de goeie indexen legt.

De manier die jij hier voorstelt is gewoon geknoei.

[Varienaja]

whoami schreef op 11 oktober 2002 @ 14:02:
De manier die jij hier voorstelt is gewoon geknoei.

Precies.

Ik vergelijk zoeken altijd met een telefoonboek. Hoe lang duurt het voordat je iemand hebt gevonden in een telefoonboek van 50 bladzijden? En hoe lang duurt dat in een boek van 1000 bladzijden? 20x zo lang? Dacht 't nie...

[cameodski]

Tja, lijkt wel een beetje op dat spreekwoord over die twee blinden die samen in de gracht vallen.
Klinkt misschien een beetje onvriendelijk, maar de waarheid is soms helaas nogal hard.