27. marts 2003 - 09:48Der er
41 kommentarer og 2 løsninger
Råd om database design
Jeg er ved at lave en database, der skal indeholde en oversigt over data-CD'er. Databasen kaldes fra et VB program, hvor der også kan foretages beregninger.
Databasen kommer til at indeholde (snittal): 500 CD'er, der hver har 200 mapper, der hver har 10 filer
-altså i alt ca. 1 million filer, hvor der skal gemmes Mappe, Navn og størrelse for hver fil. Databasen skal kunne udføre fritekstsøgning på både mapper og filer.
Hvordan struktureres dette bedst?
PT kører jeg med en model hvor der er en mappetabel og en filtabel for hver CD, altså ca 1000 tabeller. Dette er rimeligt overskueligt, men jo ikke særligt Normaliseret.
Når der skal laves søgning på feks filnavne, så skal jeg holde parametrene i nogle variable, indtil der er lavet 500 forespørgsler i de 500 filtabeller, og derefter samle det hele. Det er rimeligt plads/processor krævende.
Var det bedre at placere alle filer i én Megatabel, med 1 million poster? Så skulle jeg kun lave én forespørgsel for at lave en fritekstsøgning. ;-) Eller Hvad?
Kom endelig med noget input til hvordan denne DB opbygges smartest.
Jeg har valgt at se helt bort fra indlæsnings-delen i disse overvejelser. Så hvis du har nogle forslag der involverer en anderledes indlæsning med andre parametre, er det også helt OK.
Jeg har sat 200 ind, da jeg håber på mange besvarelser til at deles om pointene.
CDID er f.eks. af typen INTEGER, MENS CDnavnet måske er et tekstfelt med 10 tegn. En Integer optager 2 byte, mens text (så vidt jeg lige husker) bruger 1 byte pr. karakter dvs. her er det 10 byte.
Dvs. hver gang du skriver et cd-navn i forbindelse med en fil, sparer du plads i databasen svarende til 8 byte (hvis dit tekstfelt er på 10 byte). Det gør du så lige 1 million gange - så bliver det pludselig til meget.
Det samme gælder for mapper, hvor du formodentlig blot skal bruge en tekststreng, der er betydeligt længere en de 10 tegn - dermed bliver pladsbesparelsen også væsentligt større.
Du har naturligvis ret, -jeg kan oplyse at jeg har implementeret dette 100% Mine tabeller ser sådan ud PT (men jeg regner med at dette skal laves helt om):
tblINFO oversigtstabel 1 stk -diverse tblINDEX oversigtstabel 1 stk -INDEX_CDID -osv tblFolder00X mappetabel ca 500 stk -FOLDER_ID -FOLDER_CDID -FOLDER_ParentFolderID -FOLDER_Name -excl sti tblFILE00X filtabel ca 500 stk -FILE_ID -FILE_ParentFolderID -FILE_Name -excl sti og ext -FILE_Size -FILE_TypeID tblType filtypetabel 1 stk ca 400 poster -TYPE_ID -TYPE_Ext -TYPE_Desc filtypebeskrivelse
-Det er alt. Det er forsøgt Normaliseret så meget som overhovedet muligt.
Husk lige at access 97 kun kan styre databaser til 1gb. Access xp er grensen 2gb. Så hvis du mener du overskrider grenserne så lav en deling af dine data allerede i decingfacen. Vh Henrik
Så vidt jeg lige kan se, så har du faktisk gjort det så optimalt som det overhovedet kan blive. Det skal du sådan set bare læse som at jeg ikke ville have lavet det anderledes :o)
Lige en enkelt kommetar vedr. Text-felter: ifølge MS, så er det ligegyldigt om feltet sættes til 20 karakterer eller 255 karakterer. Feltet optager kun den plads, som det indtastede fylder. Der reserveres altså ikke plads til alle de ikke-anvendte karakterer. Det er da væsentligt information (og noget som jeg ikke vidste før nu).
Jeg tænker lige lidt over tabellerne. Jeg havde ikke lige læst det på den måde før, for det er da ukristeligt mange tabeller. Jeg havde læst det som om du havde 5 (fem!) tabeller.
Er der nogen speciel grund til at have så mange tabeller? Med andre ord: kræves der ekstra felter, hvis alle tabellerne blev lagt sammen til én tabel (altså én for mapper og én for filer)?
Det er afgjort væsentligt: Den teoretiske størrelse (Hvis man tager alle felters max byteforbrug) for min db med 1 mill poster er ca. 900 Mb I praksis vil den fylde -som sagt- 50-150 Mb.
Jeg har pt 250.000 poster inde i en testdb, -den fylder 17,5 Mb.
Den eneste grund, der skulle være til at dele det op i mange små, er hvis det er mere overskueligt for dig. Der er ikke noget problem for Access (så vidt jeg ved) ved at det hele ligger i én stor tabel. Som du selv har nævnt, så giver det en række problemer (i bl.a. søgninger) når tabellerne deles op, så der skal være vægtige grunde til at dele en tabel op i flere små.
Det skal siges at databasen kaldes fra et VB program, der bl.a. har en browserfunktion i en ListView. DVS at der vil være hyppige opslag i DB for at finde en fil/mappes sti og filer/undermapper. De går jo hurtigere med 1000-tabelstrukturen, da databasen kun skal søge i 2000 filer i én Filtabel.
Hvis dit program ved præcist hvilken tabel, det skal kigge i, så er det korrekt, hvis det derimod skal se flere tabeller igennem inden det finder den rigtige, så er gevinsten væk igen.
Du skal måske overveje den primære brug af databasen. Hvis det er som det førstnævnte opslag (altså hvor man ved præcist hvilken tabel, der skal søges i), så er den nuværende struktur sikkert god nok. Hvis den primære brug kræver at man skal kigge flere tabeller igennem, så ville jeg nok slå det sammen til en stor tabel.
Det kan måske også kræve lidt performance-undersøgelser: hvor mange data kan der være i en tabel, før det påvirker dit VB-program VÆSENTLIGT. Det kan da godt være at det kører næsten ligeså hurtigt, selvom der er 5000, 10000 eller 100000 eller måske en hel million poster i en tabel (det kan kun undersøges ved en praktisk test).
Hvis jeg ønsker en flot grafisk brugerflade (Browser), så vælger jeg 1000 tabeller, men taber på funktionaliteten (fritekst søgehastighed).
Hvis jeg ønsker en hurtig fritekst søgning, så vælger jeg 1 tabel, men taber på brugervenligheden, da opslag til opdatering af Browser vil være langsommere.
Jeg kan godt forstå din begrundelse, men jeg har selv tidligere fået nogen alvorlige overraskelser over hvor hurtigt Access kan afvikle forespøgsler - bare man har en ordentlig PC med masser af RAM :-)
Du har ret i det med Performance, men hvis nu dette program skulle distribueres (det skal det ikke), så ville brugerens system jo spille ind i denne sammenhæng, så jeg vil nok vælge en 'solid' løsning. Altså den hurtigste måde på en gammel maskine. Der tror jeg antallet spiller en rolle. Det er muligt at en 2 GHz processor kan lave 1 mill opslag lynhurtigt, men det tror jeg ikke en Pentium 125 MHz kan.
Det har du helt ret i. Faktisk stammer mit eget eksempel fra en 300 MHz Pentium II, og så kørte jeg en dag programmet på en 1400 MHz Pentium III. Det skete simpelthen så hurtigt at jeg troede der var noget galt. Resultatet er blot at jeg, når jeg distribuerer databasen, fortæller (og det lægger jeg meget vægt på), at databasen skal køre på en hurtig maskine. Programmet kan afvilkes på de langsomme maskiner, men så må man være forberedt på, at afviklingen tager længere tid. Det har de fleste forståelse for, og jeg oplever ofte, at folk bruger databasen som den gode undskyldning (som de har ledt længe efter) for at få en ny PC.
For i øvrigt: Nej jeg har ikke testet forskellen, og jeg er ikke sikker på den ville være væsentlig. Jeg er selv rimelig lavt kørende: 700 mHz, 256 Ram
Det lyder som du er ret fornuftigt udstyret (altså hvad PC angår). Jeg har tidligere (helt tilbage i de unge Windows 97 dage) prøvet at øge RAM fra 64 til 128 MB og oplevet en helt kolossal forbedring i Access' ydelse. Om dette også gælder når vi tale om dine mange data ved jeg ikke, men tror det umiddelbart ikke (et tydeligt tegn er langsom afvikling og megen diskaktivitet). Jeg selv er vist helt fri for den slags foreløbig - 512 MB :-)
Nu er jeg ikke den store haj til Access. Hvis det var en SQL-server, så ville jeg lave et view, der joiner alle tabeller og lave min fritekstsøgning der.
Jeg tror at jeg -indtil der kommer bedre argumenter på banen- bliver ved de 1000 tabeller. Browseren er en vigtig funktion i programmet, og her kan der altså kun bruges en vis mængde poster ad gangen, ellers tager det for lang tid at befolke TreeView og ListView kontrollerne. Derfor bliver der vist én CD ad gangen, og brugeren vælger så en anden CD fra en liste. På denne måde skal der højst vises ca 200 mapper og/eller 2000 filer ad gangen.
(Selvom MSDN CD1 var ved at tage livet af den: 2600 mapper - 27000 filer)
Hvis det er sammenlægningen af de mange tabeller (i forbindelse med en søgning) der er problemet, kan du jo også bruge en UNION query (selvom jeg aldrig har prøvet det med 1000 tabeller).
Det ved jeg faktisk ikke, men så kan du jo lave en række forespørgsler, der laver en UNION på de andre forespørgsler. Det bliver godt nok kompliceret, og jeg ved slet ikke om man overhovedet kan.
Jeg kan lige fortælle at for mit vedkommende er det egentlig ikke er Access, der sætter grænsen, men derimod Jet4.0 Engine.
I forbindelse med afvikling af mit VB program bliver Access aldrig åbnet, og database filerne kalder jeg heller ikke .mdb. Databasen -og alle tabeller m.m. bliver oprettet rent programmelt fra VB, og jeg har ingen referencer til Access. Kun til Jet.
Nu har jeg bare stillet spm her, da jeg sætter Jet4.0 = Access
Så behøver du jo slet ikke Access! PowerBasic laver en meget hurtig og effektiv index manager, som også kan bruges til VB. PowerTree koster USD 99. Se PowerBasic.com
>>fynbohans Jeg har ingen intentioner om at bruge penge på dette projekt. -Desuden kender jeg noget til Access, og vil helst bruge den som 'model'. Endelig er der overvejelser omkring distribution. Programmet skal IKKE distribueres, men jeg vil lave det som om det skulle. DVS det skal være tilgængelig for så mange som muligt.
Forstår udmærket at du gerne vil bruge Access. Skærmbilleder og alt muligt andet er meget nemt og hurtigt at lave og bruger det selv i stor udstrækning. Mange projekter kan i Access lavet på dage, hvor det ville tage uger eller måneder, hvis det hele skulle bygges op fra grunden i VB (eller PB!). Der har været adskillige forslag, men det skulle være muligt at lave det rimeligt hurtigt og nemt, så her er mit forslag uden for mange detaljer.
Der skal bruges 3 tabeller og der søges kun i den ene. Tabel 1 er CD-navne med 2 felter: CDnavn og CDID og for en sikkerheds skyld laver du det selv med tal fra 1-999. Tabel 2 er tilsvarende for mapper, Mappenavn og MappeID 10-9990 med et interval på 10. Du er nu i stand til ved hjælp af et 7-cifret tal (TotalID = 10000*CDID + MappeID) entydigt af bestemme alle mapper. CDID finder du med TotalID\10000 og MappeID med MOD 10000.
Tabel 3 indeholder filnavne som indekseres (husk at afmærke "dubletter tillades"), filstørrelse og TotalID + 1. Til denne tabel føjes mappenavne i samme felt som filnavne uden at lægge 1 til. Du kan nu nemt finde CDnavne og filnavne med MOD 2, hvor resultatet bliver 0 eller 1. Brugeren kan eventult klikke på mappenavnet og få vist filerne. Al søgning fortages i Tabel 3 med DoCmd.FindRecord.
Formuleringen omkring Tabel 2 er uklar. Denne tabel skal naturligvis indeholde det jeg hat kaldt TotalID og du finder alle mapper på en given CD med TotalID\10000. MappeID skal du kun bruge hvis du i forvejen har tabeller med alle mapper på en given CD.
fynbohans Jeg synes forslaget med en karakteropdelt ID er interessant, men spekulerer lidt på, om beregningerne i forbindelse med søgning på ID ikke vil være ret langsomme (når der nu er så mange data som vi snakker om her). Jeg synes som sagt at det lyder spændende, men der er noget ting ved dit forslag som jeg ikke helt forstår:
- Gemmer du både CDNavn, mappenavn og filnavn i tabel3? - Hvis ja, så er det vel spild at lave tabel1 og tabel2? Og husk du får problemet med at skulle vedligeholde flere tabeller med de samme data (det er aldrig en god ide). - Vil du ikke også finde filnavne, når du bruger MOD 2 på TotalID (eller er forslaget at man f.eks. har en mappe med TotalID 4550 så skal alle de ti filer i denne mappe have totalID 4551?)
I må undskylde forsinkelsen. -Jeg har været ude at rejse, og havde ikke tid/lyst til at gå på Eksperten.
I skal alle (især superjap) have tak for indsatsen. Siden jeg stillede spørgsmålet har jeg haft lejlighed til at køre diverse tests. Specielt med henblik på Access's evner til fritekstsøgning i store tabeller. Det går fantastisk hurtigt. Se spm: http://www.eksperten.dk/spm/334349 , som er en udløber af min og superjaps diskussion i dette spørgsmål.
Derfor: Jeg behøver slet ikke at lave alle de krumspring, selvom VB er inde over, og der er nogle kontroller der skal populeres.
Jeg er nået frem til, at lave en strengt hierakisk, relationel database, der er totalt normaliseret. DVS én tabel til CD'ere (ca 500 records), én tabel til mapper (ca 100.000 records) og én tabel til filer (ca 1.000.000 records).
Selv en fritekstsøgning i filtabellen tager ikke mere end 50 millisekunder! (dette forudsætter at tabellen ligger i Windows cache/swapfil, men det gør den også!)
Dine overvejelser omkring tabeldesign vil jeg dog tage op til overvejelse, fynbohans. Som det ser ud nu, så er det ikke [nødvendigt], men det er jo altid et mål i sig selv at minimere!
Tak for det. Det var jo godt du kunne bruge alle vores ord og meninger til noget :-)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
