Forespørgsel i 500 tabeller, hvordan?

Er det bestemte data der søges efter. Kan du jo lave en lykke, der tager forespørgslerne en for en. Styringen af det kan du lave i macro. Under "Kør forespørgsel" i linje 1 + linje 2 "Kør forespørgsel" osv. Jeg må ved 500 forespørgsler foreslå det deles i ca. 10 makroer. Altså så makro1 starter makro2 osv.
Vh Henrik

hvad med union select?

select * from tabel1
union select * from tabel2

Jeg må sige at det virker helt hen i vejret at lave 500 tabeller, hvis du skal lave 1 forespørgsel på hver af de 500 tabeller kommer det til at nedsætte performance betydeligt.

Hvis du deler det hele op i mindre tabeller mister du jo hele fordelen ved at lave index. 1 million records er da ikke noget at blive skræmt over, fritekst søgning i 1 million records, der ville jeg begynde at bekymre mig. Men med fritekst søgning i 1 million records fordelt på 500 tabeller, så er det vist på tide at finde mave medicinen frem.

Jeg fandt lige svaret selv på det sidste spm:

Access accepterer højst 32 tabeller i en forespørgsel, og højst 255 felter.

>>Henrik13  Det er jo sådan jeg gør nu?

>>mundi    I det refererede spm kan du se hvorfor. Det er noget med at opdatere nogle kontroller på en form, hvor det skal gå hurtigt. Men hvis
fritekstsøgning i 1 mill records går 'rimelig' hurtigt, så er der intet i
vejen for at slå de 500 tabeller sammen til en.

JOINs on 500 tables will never go, even if it was possible.

I havent looked so closely at the original question but sounds to be as though you need to redesign!
Do you have one table for each CD or what?

The design superjap suggests also seems to be about right
tblCD
CDID CDNavn

tblMappe
MappeID MappeNavn

tblFil
CDID CDID MappeID Filnavn

There is no limit to the number of records access can have but the max size of the dB which is 2 Gb for 2000/XP.

If your concerned about performance the concider using SQL Server or even MDSE (cut down version of SQL server with a max db size of 2 Gb and optimised for 5 users).

using MSDE will help lots with performance as it is a true server which Access is NOT.

Hej Terry

Selve Normaliseringen har jeg styr på.
Det ER 1 tabel for hver CD.

Grunden til de 500 tabeller er at jeg har en ListView kontrol, der fungerer som en Browser for databasen. Her skal man kunne skifte sti/mappe hurtigt.
(Uden synlig forsinkelse).
Hvis nu Jeg skal finde en fil/mappes sti eller filer/undermapper i en stor tabel med 1 mill records, tager det så ikke for lang tid?

/tjacob

PS Selve DB bliver på ca 50-150 Mb med 1 mill records.

Jeg har læst det referede spg.

Fritekst søgning i 1 tabel med 1 million records vil gå langt hurtigere end fritekst søgning i 500 tabeller på samme tid. HVis jeg altså har forstået det rigtigt.
Jeg har selv haft tabeller med ½ million records i, de leverede svar på under et sekund og blev brugt på et website hvor der var 50.000 registrede brugere (i dag over 100000).  Hvis du _skal_ søge alle data igennem er det i mine øjne klart at foretrække at det hele ligger i en tabel.

Det vigtigste er optimering af SQL og felttyper/størrelser samt indexering af alt hvad defr kan indexeres, godt nok tager det lidt længere tid at lægge data i databasen men det kan helt klart betale sig i forhold til den performance fordel du får i sidste ende..

Hvis du så kan lave en eller flere kategori inddelinger af cd'erne sådan at dit søgeområde kan afgrænses ville de jo heller ikke gøre noget :-)

og hvis alligevel er ude i noget med at lave views eller unioins på alle tabellene, så ender du jo i sidste ende jo alligevel med 1 million records der skal søges igennem

>>mundi
Jeg er helt indstillet på at lave lidt ekstra arbejde i programmerings og indlæsningsfasen. Det absolut vigtigste i denne sammenhæng er Performance.

ok, hvis du gerne vil finde en fils sti ved at bruge en listview, og du har en million records, så er det vel bare at indexere filnavnene i databasen. jeg vil ikke tro det tager mere end ½ sekund at finde filnavnene i en million recors hvis de er ordenligt indexeret. Det er mit bud

du kan jo prøve at indsætte en million records i en database med tilfældigt genereret tekst, indexere det og derefter prøve at lave en søgning og se hvor lang tid det tager, det burde ikke tage så lang tid at lave den testopstilling

Jeg er i gang ;-)

det tager jo nok sin tid at sætte 1 million records ind :-)

lige præcis:
i første forsøg glemte jeg at indsætte DoEvents, så min PC fik pludselig forrygende travlt!    ;-)

If your table is indexed then it will go VERY fast even with 1 million records. If you JOIN tables then things start getting slower specially with Access because all the data gets transported over the net. If it was in MSDE then only the data which is needed is returned. So my suggestion IF you can accept the limitations of MSDE is to place all your eggs in one basket and use MSDE.

Så har jeg kørt en test:

med min maskine:  700 MHz, 256 Mb Ram

med 1 million records var den hurtigste tid 32 millisec
Hvis jeg genstarter computeren (tømmer cachen), så var den længste tid 400 millisecs.

Så der er ingen tvivl:  Jeg skal have samlet det til én tabel.

-Og jeg vil overveje MSDE Terry, men det ser ud til at Access godt kan klare denne her.............  ;-)

/tjacob

/tjacob

godt at høre :-)

Dette var på fritekstsøgning på et felt

Isnt Access just great :o)

Jeg fik ikke svar på mit spm, men til gengæld fik jeg redesignet min DB, så spørgsmålet er irrelevant.

  40 til -mundi-
  20 til Terry

  OK?
  -opret et svar mundi

/tjacob

takker

selv tak :o)

Korrektion:

I førnævnte test havde jeg reelt ikke slukket PC'en for at tømme cachen, -blot udført nogle andre operationer.
Hvis jeg genstarter PC'en så er den langsomste tid ca 3 sekunder.

Dette er imidlertid irrelevant, fordi ved opstart af mit program, VIL dataene blive cached af Windows, og alle efterfølgende søgninger vil tage 32 - 60 millisec. Så det er OK. Men det illustrerer jo tydeligt betydningen af cache/pagefile i Windows.

/tjacob