14. juni 2001 - 14:13Der er
7 kommentarer og 4 løsninger
Arbejdsmetoder med Access 97
Jeg har i tidligere database strukture altid lavet et id som primærnølge i mine tabeller. Dette består altid af et fortløbende tal. Nu har jeg opdaget at andre Access brugere lægger primærnøglen på en tekst, og bruger noget der hedder et \"opslags-felt\", til at binde tabellerne sammen. Her er de to strukture:
(P) er primærnåøgle (Opslag) er et opslags felt
Struktur 1: ---------------------------------------------- Forfatter: id tal (P) navn tekst
Bog: id tal (P) ISBN tekst Titel tekst Forfatter tal <-- det virker som henvisning
Struktur 2: ---------------------------------------------- Forfatter: navn tekst (P)
Bog: ISBN tekst (P) Titel tekst Forfatter tekst (OPSLAG) <-- Her er opslaget
Jeg kunne godt tænke mig at vide et par ting:
Er et opslagsfelt en \"pointer\" til et felt i en anden tabel, eller er det en kopi? Hvis det er en \"pointer\", må en almindelige select være en JOIN, eller hvàd? Primærnøglen på et tal kontra en tekst, må give preformance forskel, elle hvad? Hvad er forskellen i prefomance på de to metoder? Hvad er tilsidst den \"bedste\" metode?
Kommer med flere spørsmål når jeg støder på dem....
Opslagsfeltet er det felt som refererer til et felt i en anden tabel. Her vil Forfatter feltet i Bog tabellen højst sandsynlig referere til navn feltet i Forfatter tabellen.
Du bruger derfor mindre felter, ved denne metode. Men hvis nu navn-feltet i Forfatter-tabellen er af typen memo, så ville Forfatter-feltet i Bog-tabellen jo også skulle være af memo-typen, og det vil jo komme til at fylde i længden.
Lad os lige slå fast: Man bør ALTID benytte numeriske nøglefelter!! At bruge Tekst-felter som nøgle giver meget dårlig performance. Bla. fordi et Langt heltal kun fylder 4 karakter, mens et tekst-felt typisk er på mere en 4 karakterer.
Når man snakker om opslagsfelter, kan det gøres på flere måder. Igen er det optimale at benytte et langt heltal som referencefelt og derved benytte samme felt som nøgle i opslagstabellen. Så vidt jeg kan se, er det sådan du selv har lavet det.
Jeg vil dog gerne forsvare brugen af tekstfelter som primære nøgler. Hvis du har en database som du har beskrevet ovenfor, mener jeg sagtens du kan bruge forfatternavnet som primærnøgle i en tabel udelukkende med forfattere, der så vil virke som et \"lager\" af forfattere du kan plukke fra ved oprettelse af nye bøger i en anden tabel. Selvfølgelig vil du kunne risikere at du får 2 forfattere med samme navn. Dette kan du dog undgå ved at bruge sammensatte nøgler. Så vidt jeg husker kan du benytte op til 10 felter til sammensatte nøgler.
Jeg benytter i vid udstrækning opslagsfelter (kombinationsbokse), idet dette eliminerer stavefejl hvis du samtidig sætter kombinationsboksens egenskab \"Adgangtilliste\" til Nej. På denne måde kan du ikke oprette andre poster end dem du i forvejen har i dit \"forfatterlager\".
Jeg har lavet Musikkartoteket på samme måde. Prøv at se i relationsvinduet hvordan den er skruet sammen af relationer mellem nøglefelterne.
Hvad er hurtigst, at selecte med en JOIN i struktur 1, for at hente noget fra begge tabeller, eller en almindelig select som er alt der er nødvendigt i struktur2?
I agree with thomas, you shouldnt use text fields as primary keys, the index will fill much more than a four byte index, and will be far slower if there are many records. In your Book/Author database the field in the book containing a (pointer) to the author, which is normally refewred to as a foreign key, would normally also be indexed. So again, keeping the primary key as a number will also maintain good performance when you have the foreign key indexed too.
When you make a lookup field you can use a wizard for choosing which tabel the primary key is in, also which fields you want to see in your combo box. If you choose the Author ID and the Author name the ID can be hidden so you only get to see the name, but when the record is save the ID (number) is saved in the foreign key in the book record. So, as a user to \'LOOKS\' as though your choosing a name but in fact your choosing an ID, and all your keys are numbers which saves having large slow text keys/indexes...
Stig->Din \"Struktur 1\" må siges at være den mest korrekte (der kan dog være situationer, hvor man kan forsvare at gå på kompromis og vælge Struktur 2 - den er f.eks. en anelse hurtigere at implementere. Men hvis databmængderne bliver bare lille smule store, så er det Struktur 1 der skal benyttes.
Når folk snakker om opslagsfelter, så menes der bare at brugeren får lov at vælge værdier fra en tabel (f.eks. vha en kombinationsboks eller listeboks)
Hvis du skal lave en samlet udtræk af din Struktur 1, så skal du ganske rigtigt bare lave en alm select med en join mellem de 2 tabeller. Du kan godt kalde det en pointer, men den terminologi benyttes normalt ikke i denne forbindelse.
Konklusion: Jeg tror, at du i virkeligheden har helt styr på det, men af en eller anden grund, så tror du, at det er mere kompliceret end som så. Bare et gæt :o)
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.
