Access limits

det bliver godt nok noget af en seriøs tabel..... jo Access kan godt håndtere opgaven, men hvis jeg var dig.... er jo lidt svært når jeg ikke ved hvad din dB skal kunne håndtere..... så vil jeg vælge at normalisere og opdele i 3 tabeller og så relatere dem til hinanden...

ex
tabel 1
PersonID (p-nøgle)
Navn etc

tabel 2
VareID (p-nøgle)
Varenavn etc

tabel 3
PersonID
vareID

i tabel 3 har du så registreret hvilke varer de forskellige personer bruger............ er ikke en gang sikker på det er nok... afhænger af hvad din dB skal kunne :)

Hvid det drejer sig om et simpelt skema med personerne henad og varerne nedad vile jeg bruge Access, men som Susanne skirver, ville en lidt mere detaljeret forklaring kunne give et mere kvalificeret svar.

Hvis du har under 255 personer, så vil det kunne lade sig gøre. Access kan vist ikke håndtere mere end 255 kolonner.
Men jeg vil give Susanne ret i, at det er mere optimalt at normalisere, som hun beskriver. Derved er du ikke låst fast i noget bestemt antal relationer.
Endvidere kan du altid vælge at vise dine data i en krydstabulering, således at du får dit skema-format alligevel.

Jeg har egentlig ikke brug for skemaformen som sådan, men skal bare kunne se, hvilken relation hver eneste vare har til hver person... og jeg kunne sagtens komme op på mere end 255 personer?!

Dvs. ud for hver vare skal der være en status (1 eller 2) om hver person, som jeg så kan trække ud med ASP... dvs. søges på person 139 skal man herefter kunne hive dennes relation ud omkring alle varerne - er status 1 eller 2...

Hm lyder måske lidt kringlet, men håber I ved hvad jeg mener :)

mhh ok du slipper ikke udenom en normalisering...

i din tabel nr 3 kan du så fx have flg felter

PersonID
VareID
Status

i og med du har 2 nøgler i din tabel3 vil du altid vha forespørgsel kunne finde ud af hvad personen har af varer + status OG
hvad varer der er knyttet til en person + status

det gode ved normaliseringen er bla at dine varer og personer kun står EN gang i tabel 1 og 2......

lettere at ajourføre :)

Susanne >> Vil det sige du mener jeg skal have 3 kolonner i tabel 3 (personID, VareID og Status) og så lave 250 x 1000 rækker ???

Nu er jeg dog ikke sikker på jeg ved hvad normalisering dækker over, men som jeg forstår dig, skal jeg lave en række pr. vare pr. person? Dvs. 250.000 rækker?

Ved at have det hele i én tabel, har jeg da stadig kun varer og personer én gang i tabellen...

Formålet med at normalisere er at undgå redundans (gentagelser), dvs undgå at samme information registreres flere steder. Hvis du har redundans bliver det uhyre besværligt at ajourføre databasen.....

ok lidt mere - du skal have nogen primære tabeller hvor du kun registrerer tingen EN gang. Du kobler så dine primære tabeller (tabel1 og tabel2), sammen med tabel 3 via en-til-mange relationer

Tabel1 er relateret til tabel3 via PersonID
Tabel2 er relateret til tabel3 via VareID

exsempel i tabel1 har du flg registreret

PersonID: 1
Navn: Susanne

PersonID: 2
Navn: 3Z


I tabel 2 har du
VareID 10
Varenavn: Gulerødder
Pris: 10,00

VareID 11
Varenavn: Agurker
Pris: 2,00



OK nu skal en person købe en vare, dette registreres i tabel3

PersonID: 1
VareID: 10
Tidspunkt: 10:14
Status: 1

Du bliver nødt til at have 3 primærnøgler i tabel3 (PersonID, VareID og Tidspunkt), ellers er det ikke muligt at en person kan købe en vare mere end en gang. Har tilføjet Tidspunkt som p- nøgle, da der ikke er nogen risiko for at den samme person forsøger at købe den samme vare mere end en gang samtidig….. Du kan selvfølgelig også vælge en anden nøgle, MEN du kan IKKE nøjes med det felt du kalder status (med værdi 1 eller 2)

Ved godt at det lydder underligt at det er bedre at have en tabel med 250.000 end bare vælge at registrere det hele i EN tabel, men tro mig - du kommer til at fortryde det hvis du registrerer det hele i EN tabel :)

ved sgi ikke hvorfor der pludselig sniger sig flg ind....

samtidig&#8230 ????? har bare sat nogle punktummer :)

>3Z
hvad så har du opgivet det hele???

Antallet af forskellige muligheder med så store tal er astronomisk.
Man er derfor nødt til at bruge de mindste enheder der er til
rådighed, nemlig bits.
Et Stort Heltal indeholder 32 bits og 32 felter med Stort Heltal dækker
derfor 32 x 32 = 1024 muligheder. Koden i VBA er ikke særlig 
kompliceret.
Der vil altså med dette antal felter være være plads til 1024 varer
og lige så mange personer der ønskes og relationen er enten 0 eller 1.

Inddateringen er ukompliceret. Man henter en person og ved hjælp
af en liste varen. Indaterer med en Ja/Nej-knap. 

Undskyld til Susanne! Sidst jeg nævnte bitvektorer blev hun skrækslagen,
men det er faktisk slet ikke så indviklet.

>fynbohans :)
nej det siger du jo :)

forskrækket og forskrækket :)
havde bare aldrig overvejet den mulighed.... når jeg hører udtrykkene bits, byte, mb osv tænker jeg udelukkende i pc-baner ikke access - G****

det du anbefaler er det så at samle det hele i en tabel, og styre udelukkende med vba, udelade at normalisere, eller ???

Kan jo vælge at normalisere og så sætte egenskaben på de forskellige felter på tabelniveau derefter....

Der skal bruges 2 tabeller:

Tabel1
VareNr
VareNavn

Tabel2
PersonNr
PersonNavn
32 talfelter [1]  ......  [32], Stort Heltal.

Alle talfelterne skal opdateres til 0 før start.
Varer er altså delt i 32 grupper med 32 enheder i hver.

Hvis men f.eks. vil finde en persons status for varenr.7 (Nr=7) finder vi først gruppen
i en SELECT CASE med CASE 1 - 32 ............. CASE 993 to 1024. Dernæst i vort exempel

Tal = [1]

END SELECT

Test = Tal and 2^(Nr-1) 
IF Test = 0 THEN
  Status = 0
ELSE
  Status = 1
END IF

Opdatering er lige så enkelt:

Efter SELECT CASE

Tal = [1]
Test = Tal AND 2^(Nr-1)
IF Test = 0 THEN Tal = Tal + 2^(Nr-1)  ' opdatering til 1
IF Test <> 0 THEN Tal = Tal - 2^(Nr-1) ' opdatering til 0

[1] = Tal

>fynbohans
mhh ret enkelt :)

men det ser nu ikke meget ud til at 3Z er interesseret i en løsning. Kan selvfølgelig være han/hun foretrækker at have alle info i en tabel :)

Jo jeg er her skam endnu Susanne - jeg havde bare ikke lige besluttet mig for hvad jeg skulle... jeg var i "overvejelses mode" :)

Har dog fundet ud af at jeg nok ikke behøver sammenligne alle varer med alle personer, men har dog alligevel lavet flere tabeller for nemhedens skyld...

Point til Susanne for hurtigt og fyldestgørende svar :)

>3Z
var begyndt at overveje om jeg ikke havde beskrevet sagen godt nok.....

god ide at tænke seriøst over sagen når du opretter tabeller. Hvis det ikke er genemtænkt inden man går igang med formularer mv. giver det problemer :)

Held og lykke med sagen..

Takker for points :)

Min netforbindelse forsvandt inden jeg fik sendt følgende:
Indsættes lige efter END SELECT.
Nr = Nr MOD 32
IF Nr = 0 then Nr = 32