[normalisatie]optionele gegevens

[djluc]

Ik heb het volgende probleem, even heel erg versimpeld:
Men neme een bezoeker, deze wordt geidentificeerd aan bijvoorbeeld zijn session-id. Deze komt in de tabel bezoekers te staan. Nu wil ik de bezoeker niet zomaar om zijn gegevens gaan vragen via een formuliertje maar wil ik deze doorlopend gaan aanvullen.

Neem bijvoorbeeld een gastenboek, de gebruiker is al geidentificeerd en vult hier zijn/haar naam en e-mail adres in. Waar laat ik deze gegevens? Ik kan naam in een kolom naam en e-mail in een kolom e-mail in het record zetten met de juiste session-id. Maar zoals ik al zei, de gegevens zijn niet altijd ingevuld, dan krijg ik dus een tabel met een hele hoop 'gaten.'

Wat ik ook kan doen is een aparte tabel maken met daarin de bezoekersid en het type informatie, bijvoorbeeld 1=naam.

De informatie die opgeslagen wordt kan veranderen, dan zou ik dus een kolom bij moeten maken, en mijn scripts aanpassen op die kolom. Als ik de 2de oplossing gebruik kan ik de typen informatie in een aparte tabel zetten en heb ik een heel dynamisch geheel.

Wat zou optimaler zijn, het uitlezen van oplossing 1 is eenvoudiger, maar veroorzaakt een tabel die mij niet helemaal de bedoeling lijkt omdat je zo een hoop lege velden hebt.

[gorgi_19]

Ik zou ze gewoon erin zetten, met een default value van " ".
Anders krijg je wel een heel complex iets als je query's uit wilt gaan lezen.

En wat maken die lege velden in dit geval uit? In principe hoeven ze niet leeg te zijn. Immers, je kan besluiten om later alsnog een veld te vullen of alsnog leeg te maken..

[ Voor 43% gewijzigd door gorgi_19 op 26-01-2003 16:14 ]

[djluc]

Ja dat klopt, maar dan zit ik dus wel met een heel statisch systeem, of zou ik hier misschien iets met het ophalen van kolommen(namen) kunnen doen? Of is dat eigenlijk not-done?

Het gemakkelijke aan een extra tabel leek mij dat je nog veel verder kunt gaan met je dynamiek, zo kun je een tabel maken met alle mogelijke typen informatie. Als het script wordt aangeroepen worden alle velden opgeslagen gelinkt aan die bezoeker, als een bepaald type gegevens nog niet bestaat voeg je dit gewoon toe.

[ Voor 50% gewijzigd door djluc op 26-01-2003 16:22 . Reden: een slimme? ingeving ]

[gorgi_19]

* gorgi_19 moet eens leren lezen.....

Persoonlijk zou ik gewoon heel lui zijn om de volgende kolom te maken:
BerichtId int PK
AfzenderNaam varchar(80) Default 'Anonieme bezoeker'
AfzenderEmail Varchar(80) Default 'Niet bekend'
SessionID varchar(20?)
Bericht Text

Maar je wilt variabele kolomnamen nemen?
In principe heb je alle kolommen nodig; het zal imho de scriptingtaal een worst wezen wat hij moet presenteren; als hij maar gewoon de waarden weergeeft..

Het gemakkelijke aan een extra tabel leek mij dat je nog veel verder kunt gaan met je dynamiek, zo kun je een tabel maken met alle mogelijke typen informatie. Als het script wordt aangeroepen worden alle velden opgeslagen gelinkt aan die bezoeker, als een bepaald type gegevens nog niet bestaat voeg je dit gewoon toe.

Persoonlijk heb ik een hekel aan variabele kolomnamen. De selectquery's en updatequery's worden er een stuk complexer door.

[ Voor 35% gewijzigd door gorgi_19 op 26-01-2003 16:27 ]

[tomato]

gorgi_19 schreef op 26 januari 2003 @ 16:24:
AfzenderNaam varchar(80) Default 'Anonieme bezoeker'
AfzenderEmail Varchar(80) Default 'Niet bekend'

Laat ze dan default gewoon NULL en niet 'Anonieme bezoeker' oid.

Dan is er eigenlijk niet zo veel mis mee.

Maar om hoeveel velden gaat het, echt veeeel? Zijn wel alle velden nu al bekend, of kunnen er later meer bijkomen?

[gorgi_19]

tomato schreef op 26 January 2003 @ 16:28:
[...]

Laat ze dan default gewoon NULL en niet 'Anonieme bezoeker' oid.

Dan is er eigenlijk niet zo veel mis mee.

Maar om hoeveel velden gaat het, echt veeeel? Zijn wel alle velden nu al bekend, of kunnen er later meer bijkomen?

Of die waarde correct is, ben ik met je eens..
Of je ze dan Null moet laten... Ik zou dan " " een lege waarde kiezen en geen Null; anders moet je weer controleren of een waarde " " is. Nu kan je gewoon zeggen: "Als waarde = "" laat dan zien: "anonieme bezoeker" oid.

[djluc]

gorgi_19 schreef op 26 januari 2003 @ 16:24:
* gorgi_19 moet eens leren lezen.....

Persoonlijk zou ik gewoon heel lui zijn om de volgende kolom te maken:
BerichtId int PK
AfzenderNaam varchar(80) Default 'Anonieme bezoeker'
AfzenderEmail Varchar(80) Default 'Niet bekend'
SessionID varchar(20?)
Bericht Text

Meestal ben ik dat ook, maar bij database ontwerpen wil ik het toch wel graag een beetje handig omdat ik er anders straks zelf van baal...

Maar je wilt variabele kolomnamen nemen?

Nee, het gaat er alleen om dat ik uiteindelijk heel veel verschillende dingen van de bezoeker op ga slaan, en dan lijkt het mij dat een tabel met 30 kolommen of meer waarvan een heleboel lege velden niet erg optimaal is. Ook niet om te scripten omdat je dan immense query's krijgt, zeker als je al mijn berekeningen met die gegevens straks gaat zien

In principe heb je alle kolommen nodig; het zal imho de scriptingtaal een worst wezen wat hij moet presenteren; als hij maar gewoon de waarden weergeeft..

Lekker vage zin, het maakt de taal dus niets uit maar hij moet het wel doen, oftwel zonder iets te weten moet hij wat weergeven, welke db gebruik jij, vibnd zo'n helderziende database eigenlijk ook wel gaaf, valt nog geld mee te verdienen$$

[...]

Persoonlijk heb ik een hekel aan variabele kolomnamen. De selectquery's en updatequery's worden er een stuk complexer door.[/quote]

[djluc]

tomato schreef op 26 januari 2003 @ 16:28:
[...]

Laat ze dan default gewoon NULL en niet 'Anonieme bezoeker' oid.

Dan is er eigenlijk niet zo veel mis mee.

Eigenlijk valt het dan wel mee ja.

Maar om hoeveel velden gaat het, echt veeeel? Zijn wel alle velden nu al bekend, of kunnen er later meer bijkomen?

Meer dan 30, en ja er kunnen er bijkomen, dan valt het idee van vaste kolommen dus echt af denk ik zo, dat worden dan een hoop joins..

[djluc]

Mijn huidige idee naar aanleiding van de reacties hier:
tabel typetjes: id-verplicht(1/0)-omschrijving (in formulieren krijgen alle velden met een e-mail adres bjvoorbeeld een 1
tabel gegevens: id-bezoekersid-typeid-waarde

Nog iemand commentaar op deze opzet?
oja, de tabel bezoekers wordt dan dus gewoon id-sessionid
Daardoor wordt bezoekers dus een koppeltabel tussen de sessionid en de andere gegevens.

[Zoijar]

djluc schreef op 26 januari 2003 @ 16:42:

tabel gegevens: id-bezoekersid-typeid-waarde

Waarom nog een id? bezoekersid-typeid is toch al een prima primary key? Of wil je dat er meerdere waardes ingevuld kunnen worden per type door dezelfde gebruiker?

[djluc]

Ja tuurlijk, misschien dat dat niet helemaal duidelijk was, maar als ik toch een e-mail-adres, en een naam toe wil voegen heb ik al 2 records in de tabel gegevens.

Zal even een schemaatje maken, is zometeen op djluc.nl.orion.wsgate.net/dbschema.doc te vinden.

[ Voor 1% gewijzigd door djluc op 27-01-2003 21:39 . Reden: typo ]

[djluc]

Het schema staat op bovenstaande lokatie. Er staat in het bestand ook wat uitleg over het schema. Het enige probleem wat ik momenteel nog heb staat beschreven in de tekst. Ik zou graag willen weten of ik dit nog eenvoudiger kan doen, of dat ik nog ergens iets ben vergeten.

[Glimi]

djluc
Ik zou je willen vragen wat meer gebruik te maken van de edit knop. Dmv deze knop kun je informatie bij je berichten plaatsen.
Nu lijkt het het net of je dit topic telkens 'hoog' in de topic lijst wilt hebben en zo om aandacht wil schreeuwen. Dat is dus niet toegestaan
Daarom kun je in het vervolg beter editten
[/huishoudelijkeMededeling]

[ Voor 6% gewijzigd door Glimi op 27-01-2003 23:32 ]

[djluc]

Sorry, was meer om duidelijk te maken dat het bestand er nu staat, vandaar.