[ACCESS] Database layout van een poll

[Verwijderd]

Voor mijn website maak ik een poll, gedreven door een MS Access database

Ik stel een aantal eisen aan mijn poll-systeem:
1. Ik wil onbeperkt aantal keuzes kunnen toevoegen bij een poll.
2. Ik wil alle IP adressen opslaan, inclusief poll-keuze.
3. De database structuur moet overzichtelijk blijven.

Nou had ik een structuur bedacht waardoor ik alles in één table kwijt kon.
Ik maak de volgende kolommen:

code:

| ID | Poll | Keuze | Score | IPadressen |

En een voorbeeld van een poll waar 3 mensen al op hebben gestemd zou er dan zo uit kunnen zien:

code:

| ID | Poll               | Keuze  | Score | IPadressen           |
|-----------------------------------------------------------------|
|  1 | Wat vind je van... | mooi   |     2 | 213.0.0.0; 214.0.0.0 |
|  2 | Wat vind je van... | lelijk |     1 | 215.0.0.0            |

Vervolgens kan ik op de pagina de cel IPadressen opsplitsen in een array() om vervolgens de ip-check uit te voeren in een loop.

Ik zal per poll niet meer dan 150 stemmers krijgen, dus de grootte zal niet de spuigaten uitlopen...

Het lijkt me fijn dat met deze structuur, dat het aantal records in de database beperkt blijft. Maar ik vraag me af of dit wel een snelle manier is, aangezien hij een array moet aanmaken van maximaal 150 ip-adressen. Is het (aanzienlijk) sneller om alle ip-adressen in een losse tabel te plaatsen?

Wat zijn jullie ideeën hierover? Alvast bedankt...

[Super_ik]

je design is fout
je moet iets dan van

code:

| ID | Pollnr | Keuze | IPadressen |
| ID | Pollnr | pollkeuze | evtnrvankeuze |

bvtje:

code:

| 1 | 1 | heel mooi | 1 |
| 2 | 1 | kei stom | 2 |
| 3 | 2 | jah | 1 |
| 4 | 2 | neej | 2 |

en

| 1 | 1 | 1 | 127.0.0.1 |
| 2 | 2 | 1 | 129.0.0.1 |
| 3 | 2 | 2 | 127.0.0.1 |
| 4 | 1 | 2 | 128.0.0.1 |
| 5 | 1 | 2 | 129.0.0.1 |

[ Voor 50% gewijzigd door Super_ik op 17-09-2003 22:13 ]

[whoami]

Mijn idee:

Niet zo goed. Je slaat dezelfde gegevens meerdere keren op.

Hoe ga jij nu bv op een makkelijke manier zeggen hoeveel mensen er op de poll 'Wat vind jij van GOT' op goed gestemd hebben?
Of, hoe ga jij nagaan dat en bepaald ID al eens een stem heeft uitgebracht op een poll?

Waarom maak je geen tabel Polls, waarin je de gegevens stopt van de verschillende polls, en een tabel stemmen, waarin je bijhoudt welke user (ip-adres) er op een bepaalde poll gestemd heeft, en wat zijn stem was?

[ Voor 28% gewijzigd door whoami op 17-09-2003 22:12 ]

[Verwijderd]

Hoe ga jij nu bv op een makkelijke manier zeggen hoeveel mensen er op de poll 'Wat vind jij van GOT' op goed gestemd hebben?

Dat is dus het veld 'Score' in mijn concept.

Of, hoe ga jij nagaan dat en bepaald ID al eens een stem heeft uitgebracht op een poll?

Ik kan nagaan of het huidige IP adres al reeds voorkomt in het veld 'IPadressen' van de poll waar de persoon op wil stemmen.

Waarom maak je geen tabel Polls, waarin je de gegevens stopt van de verschillende polls, en een tabel stemmen, waarin je bijhoudt welke user (ip-adres) er op een bepaalde poll gestemd heeft, en wat zijn stem was?

Zo had ik het in eerste instantie (zoals Super_ik al weergeeft). Werkt opzich wel prima, alleen maak je zo gigantisch veel records aan en heb je een extra table nodig (dus extra SQL-statement). Dus ik vroeg me af of dat al-met-al wel zo snel zou zijn.

[ Voor 5% gewijzigd door Verwijderd op 17-09-2003 22:21 ]

[whoami]

Verwijderd schreef op 17 september 2003 @ 22:20:
[...]
Dat is dus het veld 'Score' in mijn concept.


Ik kan nagaan of het huidige IP adres al reeds voorkomt in het veld 'IPadressen' van de poll waar de persoon op wil stemmen.

Ik vroeg niet of je dat kon doen, ik vroeg je hoe je dat makkelijk (met alleen SQL statements) gaat doen.

Zo had ik het in eerste instantie (zoals Super_ik al weergeeft). Werkt opzich wel prima, alleen maak je zo gigantisch veel records aan en heb je een extra table nodig (dus extra SQL-statement). Dus ik vroeg me af of dat al-met-al wel zo snel zou zijn.

Wat is veel records? 1000 ? 10.000 ? 100.000 ? Da's allemaal niet veel.
Je kan veel sneller inserts/updates doen in een genormaliseerde DB dan in een niet genormaliseerde DB.
Ook de vragen die ik daarnet stelde, zal jij niet zo snel en makkelijk kunnen beantwoorden dan als je met een goed datamodel werkt.

Nu ga jij gewoon gigantisch veel gegevens gaan dupliceren, ik zie dat je meerder ip-adressen (separated) in een veld opslaat.... Dat is gewoon een superslecht datamodel.
Als jij er nu wilt voor zorgen dat een persoon (bepaald ip-adres) geen 2x een stem kan uitbrengen voor dezelfde poll, hoe ga jij dat verwezenlijken? Je gaat heel dat veld moeten opsplitsen, en dan ip-adres per ip-adres gaan vergelijken....
Wat gaat sneller zijn denk je ?

[ Voor 20% gewijzigd door whoami op 17-09-2003 22:27 ]

[Force]

EN bij het idee van de TS loopt de lengte van het veld/kolom ipadressen al snel tegen zijn maximale lengte aan.

[whoami]

Ik denk dat de TS best toch eens even een boek leest over databases en data-modelling....

[Verwijderd]

Nu ga jij gewoon gigantisch veel gegevens gaan dupliceren, ik zie dat je meerder ip-adressen (separated) in een veld opslaat.... Dat is gewoon een superslecht datamodel.

Ok, als iedereen het daarmee eens is weet ik voldoende.. Bedankt!

Maar dan zou het concept van Super_ik dus ook niet helemaal goed zijn? Aangezien die ook IP adressen meerdere malen opslaat. Wat is dan wel de juiste indeling van de 2^e tabel? (Die waar de IP adressen instaan dus)

^{die opmerking hierboven is ook weer niet nodig}

edit:

EN bij het idee van de TS loopt de lengte van het veld/kolom ipadressen al snel tegen zijn maximale lengte aan.

Je kunt in een Memo veld (65535/17=) 3855 ip adressen opslaan op mijn manier.

Ik zal per poll niet meer dan 150 stemmers krijgen, dus de grootte zal niet de spuigaten uitlopen...

Dat lijkt me dus geen enkel probleem

[ Voor 33% gewijzigd door Verwijderd op 17-09-2003 22:38 ]

[Force]

Verwijderd schreef op 17 September 2003 @ 22:29:
[...]
Maar dan zou het concept van Super_ik dus ook niet helemaal goed zijn? Aangezien die ook IP adressen meerdere malen opslaat. Wat is dan wel de juiste indeling van de 2^e tabel? (Die waar de IP adressen instaan dus)

Ik neem aan dat je dubbel stemmen wel gaat voorkomen, dus 2e keer stemmen van hetzelfde ipadres word niet geteld, en dus ook niet opgeslagen in je tabel.

Dus bij het invoeren van een stem controleer je in die tabel of er van dat ip adres al op die poll gestemt is, zoniet dan sla je de stem op. En als het wel de tweede keer is negeer je de stem en word hij niet toegevoegd in de tabel.

[gorgi_19]

Ik neem aan dat je dubbel stemmen wel gaat voorkomen, dus 2e keer stemmen van hetzelfde ipadres word niet geteld, en dus ook niet opgeslagen in je tabel.

Nadeel is alleen als je met proxies zit..

[Verwijderd]

Nadeel is alleen als je met proxies zit..

Inderdaad, maar die mensen hebben maar pech gehad

Ik heb mijn concept uit mijn startpost getest en ik moet zeggen dat hij perfect werkt.
Parsing time wisselt tussen de 15ms en 0 ms (niet écht 0ms natuurlijk, maar bijna 0ms ). Maar dat doet hij sowieso al als ik een database open, dus eigenlijk merk je het niet qua snelheid.

Testomtandigheden:
Ik heb een database gemaakt met een poll. Bij die poll waren 10 mogelijke keuzes. Elke keuze had verschillende scores en in totaal was er (gesimuleerd) 220x gestemd. Bij elke page-refresh heb ik automatisch een ip-adres laten generen en vergeleken met alle ip-adressen uit de poll. Het resultaat was steeds: Je mag nog stemmen, of: Je hebt al gestemd.

Het enige wat dubbel in de tabel staat is de titel van de poll, daarvoor ga ik niet normaliseren omdat dit te verwaarlozen is.

edit:
Wie me niet geloofd mag hier ff testen: http://www.doenormaal.net/testpoll.asp
De database kun je hier zien: http://www.doenormaal.net/testpoll.mdb

Alle IP adressen van 192.168.123.1 tot 192.168.123.220 hebben zogenaamd al gestemd. De website genereert zelf even een IP adres tussen de 192.168.123.100 en 192.168.123.255

[ Voor 21% gewijzigd door Verwijderd op 18-09-2003 00:43 ]

[Grijze Vos]

Doe vooral eigenwijs wat je zelf wil, maar kom dan geen vragen stellen. Professoren, Doctoren en Ingenieurs van Universiteiten hebben vast die pillen van duizenden paginas geschreven over database-normalisatie, omdat het hun hobby is om nutteloze zooi te schrijven.

Op deze kleine schaal boeit het je misschien niet, maar een nette structuur is oh zo belangrijk. Je hoeft heus geen BCNF model te maken, maar de derde normaalvorm, of, evt voor websites, de 4e of 5e normaalvorm, is toch wel zo netjes. Kan misschien niet altijd, maar je kunt het beter wel proberen te handhaven...

[Verwijderd]

Beste Grijze Vos,
ik wil niet eigenwijs zijn, maar als ik wil mijzelf graag overtuigen van wat de beste manier is. Ik probeer te zeggen dat mijn ideetje best goed is, dan hoop ik dat anderen of: goed beargumenteren waarom het niet goed is, of dat anderen zeggen dat het idee best wel goed is.

Het is op deze schaal niet eens zo heel belangrijk dat alles 100% optimaal is, want het scheelt dan waarschijnlijk nog geen miliseconde. (andere delen van de database normaliseer ik uiteraard wel)

Ik heb nog steeds het vermoeden dat een extra tabel voor de ip-adressen alleen maar vertragend werkt. We hebben nu ruim 1.000 records voor IP adressen in een losse tabel. Zijn er misschien nog andere manieren dan? Waarvan jullie wel denken dat het helemaal goed is, maar waarmee je geen duizenden records maakt in een tabel?

[Wokkels]

Verwijderd schreef op 18 September 2003 @ 01:24:
[...]
Het is op deze schaal niet eens zo heel belangrijk dat alles 100% optimaal is, want het scheelt dan waarschijnlijk nog geen miliseconde. (andere delen van de database normaliseer ik uiteraard wel)

Maar op het moment dat je de schaal gaat vergroten, bijvoorbeeld omdat je polls toch meer mensen gaan trekken dan verwacht, dan krijg je toch een probleem. Want dan moet je genoegen nemen met (onevenredig) grotere parsetimes, of je moet je DB aanpassen, wat (als je de vorige resultaten wilt behouden) nog best eens erg veel werk kan zijn.

Ik heb nog steeds het vermoeden dat een extra tabel voor de ip-adressen alleen maar vertragend werkt. We hebben nu ruim 1.000 records voor IP adressen in een losse tabel. Zijn er misschien nog andere manieren dan? Waarvan jullie wel denken dat het helemaal goed is, maar waarmee je geen duizenden records maakt in een tabel?

Als je dat vermoeden hebt, dan moet je het testen. Niemand geeft je de garantie dat het op een andere manier beter of sneller werkt (alhoewel DB-ontwerpstudies ook niet uit de lucht komen vallen natuurlijk ). Ik zou zeggen, leg een paar verschillende ontwerpen naast elkaar, draai desnoods een script en kijk wat er sneller is.

[whoami]

Waarom kom je hier eigenlijk raad vragen als je toch maar eigenwijs bent, en goede raad in de wind slaat?
Trage systemen zijn meestal te wijten aan een slecht datamodel. Jouw datamodel is hier een voorbeeld van. Op een snelle manier controleren of een bepaalde gebruiker (ip-adres) al eens een stem heeft uitgebracht op een bepaalde poll zit er bij jou niet in.
Lees eens iets over datamodelling. Een van de eerste stappen die er gedaan moet worden is het voorkomen van het opslaan van meerdere waarden in 1 veld en het voorkomen van data-duplicatie.
Nu is er misschien nog niets aan de hand, maar wacht maar eens totdat een duizendtal gebruikers een stem hebben uitgebracht.

En jouw argument om de genormaliseerde structuur niet te gebruiken (cq 'om het aantal records in te perken') is gewoon een onzin.

Nouja, wie niet horen wil, zal wel moeten voelen zeker?

* whoami blijft trouwens bij z'n post waarvan jij zegt dat die opmerking niet nodig was...

[Verwijderd]

whoami schreef op 18 September 2003 @ 08:54:
...onzin...

Ik weet ook wel dat jij erg graag commentaar wilt leveren. Ik wil graag dat jij een woordenboek pakt en opzoekt wat eigenwijs betekend. Ik heb namelijk nog lang geen keuze gemaakt, ik wil alleen een discussie op gang zetten met de voor en nadelen. Als jij moeite hebt met normaal discussiëren wil je dan alsjeblieft gewoon niet meer reageren

Ten tweede: jij hebt mijn startpost niet goed genoeg doorgelezen. Het ging dus alleen om de IP adressen. En ja.. 1 IP adres komt meerdere malen voor in 1 table.. Evenals dat dat gebeurd bij de oplossing van Super_ik. Ik zie jou geen betere oplossing geven, alleen maar commentaar leveren. Als jij nou geen betere oplossing kunt geven en geen goede argumenten kunt leveren, post dan alsjeblieft niet meer

En het controleren van de IP adressen gebeurd op vrijwel dezelfde manier, gewoon door een SQL statement.

En jouw argument om de genormaliseerde structuur niet te gebruiken (cq 'om het aantal records in te perken') is gewoon een onzin.

Alsjeblieft zeg Ik zei dat ik de titel van de poll niet hoefde te normaliseren omdat die maar een paar keer terug kwam. Dat staat los van het aantal records. De IP adressen zouden veel records genereren. Heb je weer niet goed gelezen. Normaliseren werkt trouwens pas effectief bij een bepaalde schaal, mnr. Einstein!

En om nog even te zeggen dat je moeite hebt met lezen, ik zei gisteren dit:

Ok, als iedereen het daarmee eens is weet ik voldoende.. Bedankt!

Hoe kun je dan in hemelsnaam nog zeggen dat ik eigenwijs ben..

[ Voor 8% gewijzigd door Verwijderd op 18-09-2003 14:17 ]

[gorgi_19]

* gorgi_19 vraagt zich nu nog af waar deze discussie over gaat...

MS Access is absoluut niet dol op zoeken in tekstvelden, iets wat jij hem nu dwingt te doen. (kan die geen indexen op leggen)
Daarnaast ben je doodsbang voor een paar duizend records.

Veronderstellingen als: "Jammer voor de bedrijfsproxy" en "inbelaccounts zijn verwaarloosbaar om beinvloedbaar te zijn", kan je je vraagtekens bij stellen.

Maar zoals whoami zegt: Ik hoop voor je dat je enkele nadelige gevolgen niet merkt.

[ Voor 24% gewijzigd door gorgi_19 op 18-09-2003 14:21 ]

[Verwijderd]

MS Access is absoluut niet dol op zoeken in tekstvelden, iets wat jij hem nu dwingt te doen. (kan die geen indexen op leggen)

Daar heb je een punt, even nog niet bij stilgestaan. Ik denk dat ik een aparte tabel maak voor de IP adressen, maar dan zo dat elk IP adres er maar 1x in komt te staan.

Veronderstellingen als: "Jammer voor de bedrijfsproxy" en "inbelaccounts zijn verwaarloosbaar om beinvloedbaar te zijn", kan je je vraagtekens bij stellen.

Heb je wel gelijk aan, maar ik denk toch dat ik IP check prefereer boven Cookie check bijvoorbeeld. We hebben veel mensen op onze site die maar wat graag de boel verzieken. De poll is slechts een klein deel van de site, dus als iemand toevallig niet kan posten is dat geen ramp

* gorgi_19 vraagt zich nu nog af waar deze discussie over gaat...

Daar heb je ook een punt Laten we het daarom hier maar bij houden, tenzij iemand nog iets nuttigs te melden heeft. Bedankt voor jullie hulp!

^{edit: whoami, ik zal alleen nog reageren op inhoudelijke posts.}

[ Voor 6% gewijzigd door Verwijderd op 18-09-2003 14:41 ]

[whoami]

Verwijderd schreef op 18 September 2003 @ 14:14:
[...]

Ik weet ook wel dat jij erg graag commentaar wilt leveren. Ik wil graag dat jij een woordenboek pakt en opzoekt wat eigenwijs betekend. Ik heb namelijk nog lang geen keuze gemaakt, ik wil alleen een discussie op gang zetten met de voor en nadelen. Als jij moeite hebt met normaal discussiëren wil je dan alsjeblieft gewoon niet meer reageren

Uit jouw vorige posts blijkt dat je toch maar aan jouw eerste standpunt zult vasthouden.
En die , en smilies hoeven niet hoor.

Ten tweede: jij hebt mijn startpost niet goed genoeg doorgelezen. Het ging dus alleen om de IP adressen. En ja.. 1 IP adres komt meerdere malen voor in 1 table.. Evenals dat dat gebeurd bij de oplossing van Super_ik. Ik zie jou geen betere oplossing geven, alleen maar commentaar leveren. Als jij nou geen betere oplossing kunt geven en geen goede argumenten kunt leveren, post dan alsjeblieft niet meer

Daar heb ik het ook over, over die IP adressen. Dat je meerdere keren hetzelfde IP adres in een table opslaat, is niet zo erg (in dit geval).
Echter, jij slaat meerdere IP adressen op in 1 veld. Dat is veel erger.
Als jij zegt, dat ik geen oplossingen aandraag, dan moet je mijn posts nog eens goed herlezen.

En het controleren van de IP adressen gebeurd op vrijwel dezelfde manier, gewoon door een SQL statement.

Hoe dan, als je ze in 1 veld opslaat?

Alsjeblieft zeg Ik zei dat ik de titel van de poll niet hoefde te normaliseren omdat die maar een paar keer terug kwam. Dat staat los van het aantal records. De IP adressen zouden veel records genereren. Heb je weer niet goed gelezen. Normaliseren werkt trouwens pas effectief bij een bepaalde schaal, mnr. Einstein!

Normaliseren 'werkt' altijd. Je datamodel moet altijd genormaliseerd zijn, zelfs al sla je slechts een onbenullig aantal records op.

[whoami]

Verwijderd schreef op 18 September 2003 @ 14:28:
[...]
Daar heb je een punt, even nog niet bij stilgestaan. Ik denk dat ik een aparte tabel maak voor de IP adressen, maar dan zo dat elk IP adres er maar 1x in komt te staan.

Dat hoef je in dit geval niet te doen.
Je kan het ip-adres imo gewoon opnemen in je tabel waar je de stemmen in opslaat. Zei het dan wel : 1 IP adres per record:

code:

pollid   ipadres    stem
1         192.0.0.1  1
1         192.0.0.2  3
2         192.0.0.1  3

[Verwijderd]

whoami schreef op 18 September 2003 @ 14:35:
[...]

Dat hoef je in dit geval niet te doen.
Je kan het ip-adres imo gewoon opnemen in je tabel waar je de stemmen in opslaat. Zei het dan wel : 1 IP adres per record:

code:

pollid   ipadres    stem
1         192.0.0.1  1
1         192.0.0.2  3
2         192.0.0.1  3

Ok, dat wil ik best aannemen, maar ik begrijp niet waarom je dit dan niet zou normaliseren? Aangezien je na 100 pollen (raar woord ) sommige IP adressen al 100x in die tabel hebt staan.

[whoami]

Waarom zou je dit wel normaliseren?
Als je het zou normaliseren, dan zou je een tabel ip-adressen hebben, die er bv. als volgt uit ziet:
ipadres id ip adres
1 192.168.0.1

En dan sla je in je poll-tabel ipv ipadres het id op. Dat komt eigenlijk op hetzelfde neer, en je creeërt extra (onnodige) overhead, door te moeten joinen, terwijl in die andere tabel (ipadres) geen verdere relevante informatie staat.

Daarnaast kan je in je poll-tabel ook nog een unique constraint leggen op (pollid, ip-adres).

[Verwijderd]

[...]
Hoe dan, als je ze in 1 veld opslaat?

Ongeveer zo:
SELECT * FROM [Poll] WHERE [IPadressen] LIKE '% [huidige ipadres] %'

Ik heb beide manieren even getest zoals Wokkels adviseerde. Als 100 mensen tegelijkertijd hun IP adres laten controleren dan is mijn concept uit de startpost een stuk langzamer. Maar als ik simuleer met minder dan 15 mensen tegelijk dan maakt het al niets meer uit.

Wat wel een voordeel is van mijn concept is dat de database kleiner blijft. (144KB vs. 192 KB) En ik vind het persoonlijk wel iets overzichtelijker in de database.

Mijn conclusie:
Als je veel bezoekers tegelijkertijd hebt en je gaat voor snelheid, dan moet je niet mijn concept uit de startpost kiezen.

Als je graag een compacte database wilt en je hebt geen duizenden bezoekers per dag, dan kun je wel die structuur wel kiezen.

Iedereen het daar mee eens?

De Test:
http://www.doenormaal.net/testpoll.asp
(Vul in hoeveel simulaties je wilt doen)

De Databases:
http://www.doenormaal.net/database.mdb
http://www.doenormaal.net/database2.mdb

^{Whoami, is database2.mdb zoals jij het bedoeld?}

[ Voor 4% gewijzigd door Verwijderd op 18-09-2003 16:09 ]

[whoami]

Verwijderd schreef op 18 September 2003 @ 16:08:
[...]
Ongeveer zo:
SELECT * FROM [Poll] WHERE [IPadressen] LIKE '% [huidige ipadres] %'

Dat is zowiezo al traag. In dit geval kunnen er geen indexen gebruikt worden, aangezien je een wildcard gebruikt aan het begin van je zoekstring. (Het DBMS moet dan een tablescan doen).
Het gaat er niet alleen om dat het traag zal zijn bij een grote 'load' aan concurrent users, maar als er eens wat meer records in die tabel zouden zitten, zal de snelheid ook drastisch afnemen.

Wat wel een voordeel is van mijn concept is dat de database kleiner blijft. (144KB vs. 192 KB) En ik vind het persoonlijk wel iets overzichtelijker in de database.

Een database is bedoeld om gegevens op een integere manier te kunnen bewaren. De integriteit van de gegevens wordt met jouw model niet bewaard.
Hoe ga jij bv. weten welke stem welk ip-adres heeft uitgebracht op welke poll?
Of, hoe ga je een stem later verwijderen?
Ik vind er trouwens niets overzichtelijks aan. Ja, jij vind het misschien overzichtelijker als je rechtstreeks in de DB kijkt, maar dat is nu ook niet de bedoeling.

Mijn conclusie:
Als je veel bezoekers tegelijkertijd hebt en je gaat voor snelheid, dan moet je niet mijn concept uit de startpost kiezen.

Als je graag een compacte database wilt en je hebt geen duizenden bezoekers per dag, dan kun je wel die structuur wel kiezen.

Ik ben het er niet mee eens.
Onderhoudbaarheid, aanpasbaarheid, snelheid, etc.... Jouw eerste datamodel doet in ieder van die gevallen onder voor mijn voorstel. Dat zal je zeker merken eens je databank groeit.

Iedereen het daar mee eens?

Nee dus.

[Verwijderd]

Je bent een vraag vergeten

Whoami, is database2.mdb zoals jij het bedoeld?

Maar ik denk dat ik het maar doe zoals mijn concept2 is in de test Tenzij je nog verbeteringen hebt?

[whoami]

Verwijderd schreef op 18 September 2003 @ 16:08:
[...]

^{Whoami, is database2.mdb zoals jij het bedoeld?}

Nee,
mijn voorstel is zo:

tblPoll: pollid; pollnaam
tblStem: pollid, ipadres, stem

Waarvan de inhoud er dan bv zo uit ziet:
tblPoll:
1 Een willekeurige poll
2 Nog een poll

tblStem
1 192.168.0.1 goed
1 192.168.0.2 zeer goed
1 192.168.0.3 slecht
2 192.168.0.1 weinig
2 192.168.0.4 veel

Ik snap je indeling van tblIpadressen totaal niet. Wat is pollkeuze? Waarom staat pollid daar in? Waarom heb je zowel een veld ID als PollId in de tabel Polls? etc...

[ Voor 15% gewijzigd door whoami op 18-09-2003 16:22 ]

[Verwijderd]

Waar staat bij jouw indeling dan waar de mensen uit kunnen kiezen?? Bij tblStem heb je wel staan waar de mensen op hebben gestemd, maar waar haalt hij 'goed' en 'zeer goed' vandaan?

[whoami]

Ik heb het niet volledig uitgewerkt.
Die kan je natuurlijk in een andere tabel stoppen, en in tblStem sla je dan het id van de bijhorende waarde op.

[Verwijderd]

Ik heb het niet volledig uitgewerkt.
Die kan je natuurlijk in een andere tabel stoppen, en in tblStem sla je dan het id van de bijhorende waarde op.

Dat bedoelde ik
Thnx

[Grijze Vos]

Hier een voorbeeld van hoe ik het heb gedaan, in mn MySQL implementatie (IMHO btw een betere database voor web-applicates).

CREATE TABLE cv_poll_options (
POID int(11) NOT NULL auto_increment,
PID int(11) NOT NULL default '0',
POption text NOT NULL,
PRIMARY KEY (POID)
) TYPE=MyISAM COMMENT='listing of all poll options';
# --------------------------------------------------------

CREATE TABLE cv_poll_votes (
PVID int(11) NOT NULL auto_increment,
PID int(11) NOT NULL default '0',
POID int(11) NOT NULL default '0',
UID int(11) NOT NULL default '0',
PRIMARY KEY (PVID)
) TYPE=MyISAM COMMENT='listing of all poll votes';
# --------------------------------------------------------

CREATE TABLE cv_polls (
PID int(11) NOT NULL auto_increment,
PQuestion text NOT NULL,
PRIMARY KEY (PID)
) TYPE=MyISAM COMMENT='listing of all polls';

UID zou je dan moeten vervangen door IP.


Het is overigens, ook al werk je op kleine schaal, toch aan te raden het in elkaar te steken zoals het hoort. Om een aantal redenen.

1. Als er meer data in komt, wordt het verschil in performance steeds groter. (Punt van Whoami)
2. Als je userbase plotsklaps groter wordt, dan ben je gesjaakt, en kun je alsnog eraan gaan werken.
3. Wil je straks meer met je data, dan is het slecht uit te breiden.
4. Als je dezelfde code voor iets anders wil gebruiken, dan kun je probleem 1/2/3 heel snel tegenkomen.
5. Zo leer je ook nog daadwerkelijk fatsoenlijk te modelleren, en dat is nooit weg. Beetje een foute gedachte om zo te redeneren, zoals je doet. Klein voorbeeldje, quote van Bi ll Gates, ten tijde van Win 3.11: "Who would ever need more then 640 kilobytes?"

Begrijp je wat ik bedoel?