[MS Access] vereiste hoeveelheid geheugen

[bigfoot1942]

iemand heeft mij gevraagd een simpele database te maken om gegevens over patiënten bij te houden.
Dit kan gemakkelijk in 1 tabel, maar er zijn nogalk veel velden per tabel. Lees: tegen de 100. Nu zijn dat een aantal booleans, integers ("enkele precisie") en enkele (ongeveer 10) tekstvakken van 255 tekens.

Als ik dit in een formulier laat weergeven met behulp van tabbladen (dus alle velden van de betreffende record) op hoeveel geheugengebruik moet ik dan ongeveer rekenen?
Als dit teveel is, zou dit gemakkelijk op te lossen zijn? door bv de velden over 3 tabellen te spreiden?

[foske]

is toch heel makkelijk te meten? je maakt gewoon 100 velden aan (betekenisloze veldnamen) en je maakt een autoformulier. even onder taakbeheer kijken hoeveelgeheugen dit kost... 10 minuten werk, over tabellen spreiden is denk zowiezo iets waar je rekening mee moet houden (ff googlen op normalizeren, mocht je dit nog niet kennen, gaat vooral over dubbele gegevens in je database) verder denk ik dat access dit gewoon aan moet kunnen (mits je pc een beetje up to date is)

[kenneth]

Lees een boek over databaseontwerp, in het bijzonder over normaliseren, en ga dan nog 'ns nadenken over de database _{Tenminste, ik ga ervan uit dat je dat niet gedaan had, anders had je de vraag niet gesteld}

[whoami]

Euh, alle gegevens in 1 tabel, en 100 velden in die tabel?
Dat lijkt gewoon sterk op een zeer slecht datamodel.

Lees misschien eens iets over normaliseren.

[THIJZEL]

bigfoot1942 schreef op 02 februari 2004 @ 21:12:
iemand heeft mij gevraagd een simpele database te maken om gegevens over patiënten bij te houden.
Dit kan gemakkelijk in 1 tabel, maar er zijn nogalk veel velden per tabel. Lees: tegen de 100. Nu zijn dat een aantal booleans, integers ("enkele precisie") en enkele (ongeveer 10) tekstvakken van 255 tekens.

Als ik dit in een formulier laat weergeven met behulp van tabbladen (dus alle velden van de betreffende record) op hoeveel geheugengebruik moet ik dan ongeveer rekenen?
Als dit teveel is, zou dit gemakkelijk op te lossen zijn? door bv de velden over 3 tabellen te spreiden?

alle gegevens in één tabel? ik denk dat je nogal snel tegen heel wat problemen gaat aanlopen wanneer je je systeem wat wil gaan uitbreiden, of zelfs al bij het bouwen/ontwerpen..

Zoals kenneth al zegt, lees eens een boek over normaliseren. Ik zou namelijk eens wat gaan expirimenteren met meerdere tabellen en relaties daartussen.

[bigfoot1942]

* voelt zich dom, maar zal ff flink zijn zwaar ingestofte kennis over Normaliseren opfrissen

[Boss]

Waarom moet het slecht zijn om 1 tabel met 100 kolommen te hebben?

Als je model daarom vraagt...

Ik heb ook aan een patienten db voor een ziekenhuis gewerkt, en je wilt niet weten hoeveel gegevens ze allemaal bijhouden voor die patiënten. Dan kom je echt wel aan 100 velden. Kan je normaliseren wat je wil, het worden er echt niet minder.

(hoewel het wel vaag is als dat allemaal tekstvelden van 255 tekens moeten zijn)

[Verwijderd]

De vraag was volgens mij hoeveel geheugen je nodig had en dat kan je berekenen. Dan weet je wat je per record nodig hebt:

byte = 1 byte
integer = 2
long = 4
double = 8
string = 10 + het aantal karakters (in jouw geval 255)
decimal = 14
object = 4 (alleen de reference naar het object toe)

En vermenigvuldig deze datatypes maal het aantal velden wat je hebt

bijvoorbeeld:

10 velden byte = 10
2 string velden = 530
2 integer velden = 4
===============
totaal 544

Dan weet je het geheugen gebruik voor 1 record. Maar dan weet je nog niet wat het formulier gebruikt en ook dat kan je uitrekenen al wordt dit lastiger.

tel alle variabelen op de zelfde manier op. Tel dan alle controls bij elkaar op: Misschien maak ik nu een denkfout maar uitgaande van het feit dat alles een object is (je form, je textboxes, je knoppen, je tabblad) dan doe je dat aantal maal 4 en weet je bij benadering de hoeveelheid.

Let wel ieder tabcontrol = 4 plus 4 * het aantal tabbladen

Maar ik denk dat je je moet afvragen of 100 (honderd) velden op 1 form niet een beetje te veel is. Misschien moet je inderdaad eens kijken of je niet iets verder kunt normaliseren. Ga anders werken met extra schermen. adres woonplaats hoeft naar mijn idee niet altijd getoond te worden om maar iets te noemen.

Suc6 ermee

[Verwijderd]

Dan kom je echt wel aan 100 velden. Kan je normaliseren wat je wil, het worden er echt niet minder

Maar je database wordt er wel een stuk minder groot van en door slimme indexen aan te leggen wordt het ook een stuk sneller. Je hebt geen gaten meer in een 2dimensionaal array, en die kosten ook ruimte.

[bigfoot1942]

ik heb dr weer ff naar gekeken, maar normaal genormaliseerd zal er niet kunnen worden.
eventueel kan ik wel een paart tabellen in een 1 op 1 relatie aan elkaar hangen, en dan met subformulieren een soort tabbladen emuleren.
Maar heeft dat daadwerkelijk performance voordelen tov alles in 1 tabel en dat in een formulier, met tabbladen, of zit ik mezelf dan voor de gek te houden.

Maar normaliseren gaat dus echt niet lukken, het gaat gewoon over allerei eigenschappen van een patient. En ik kan dan wel een aparte tabel (bv "bloed") aanmaken die een een op een relatie heeft met "patient", maar heeft dat dus nut qua performance? Of daalt de performance juist omdat er ook nog een moeilijker querie uitgevoerd moet worden?

[RobIII]

Nee, maar je kunt een tabel maken met bloedgroepen (als voorbeeld) met daarin:

code:

BGID BGOmschr
===========
1    A neg.
2    A pos.
3    B neg.
4    B pos.
etc...

(Weet begod nie of deze bloedgroepen bestaan, ik roep maar wat. Ben een developer geen docter )

Je kunt dan bij de patient een foreign key opslaan naar bloedgroep (dus een ID, niet de bloedgroep). Nu heeft het bij bloedgroepen weinig zin, net als bij geslacht ofzo, omdat je in principe A+, A- of M/V kunt opslaan. En of je nou 1 FK gebruikt of een A+/M dat maakt weinig uit. Het heeft meer nut als je bijvoorbeeld plaatsnamen in een tabel gaat gooien (weet zo snel geen mooi voorbeeld wat je nog meer voor een patient zou kunnen gebruiken, maar you get my drift )

[CrashOne]

Je kan toch:

code:

patient-------|>---- klacht ---------|>------behandelingen
    |
     --------|>--------- reminders

Of iets dergelijks doen?

[Boss]

Om hoeveel records gaat het eigenlijk, uiteindelijk?

Ik denk nl dat er hier naar een probleem wordt gezocht dat er niet is. Ik heb ergens een Access database draaien (in access 97 nog zelfs!) met daarin in alle records 2 ingesloten OLE objecten. De totale grootte van die database is nu iets van 85mb. Een record kan dus zo 80-100 kb zijn. En het werkt allemaal prima.

Dus ik denk dat je niet bang hoeft te zijn voor een record met 100 velden.