normaliseren
Ik heb de volgende site gebruikt:
normaliseren
BERICHT
- Persoonsnaam VARCHAR
- Email VARCHAR
- title VARCHAR
- inhoud VARCHAR
- datum TIMESTAMP
- ipnummer INET
- browser VARCHAR
- avatar VARCHAR
- ID (primary key) INT(11)
PROFIEL
- Persoonsnaam VARCHAR
- ww VARCHAR
- plaats VARCHAR
- rechten ENUM(‘lid’,‘admin’)
- lidsinds TIMESTAMP
- email VARCHAR
- avatar VARCHAR
- ID (primary key) INT11
ENTITEIT
- bericht
- profiel
- bezoeker
RELATIES
Bezoeker -> bericht, 1 bezoeker kan meerdere keren een bericht plaatsen
Bericht -> bezoeker, 1 bericht wordt altijd gemaakt door 1 bezoeker tegelijk
Bezoeker -> profiel, 1 bezoeker kan maar 1 profiel hebben
Profiel -> bezoeker, 1 profiel kan maar 1 bezoeker hebben
Volgens de site moet ik nog 2 relaties hebben, met Profiel en Bericht. Maar dat kan niet, want ze staan niet aan elkaar gekoppeld (toch?)
Kan iemand mij vertellen wat ik fout doe? Ik zie door de bomen t bos niet meer :(
edit: datatypes erbij gezet
Gewijzigd op 01/01/1970 01:00:00 door Tamara
Bericht zou ik geen persoonsnaam zetten, tenzij er de mogelijkheid is om anoniem een bericht te sturen. Als dat niet het geval is (dus d.m.v. een login gegeven) zou ik in de tabel "bericht" de velden Persoonsnaam en email weglaten.
waarom zou ik de velden persoonsnaam en email moeten weglaten??
Als je met login gegevens gaat werken haal je die uit de profiel tabel, daar staan die gegevens nu eenmaal in, mij lijkt het dat je een useraccount koppeld aan een profiel.
of ben ik op t verkeerde spoor?
Dat klopt Tamara, die kant moet je op. Dat betekend wel automatisch dat het gastenboek alleen beschikbaar is voor mensen die zijn ingelogd!
maar ik wil eerst een basic gastenboek hebben gemaakt, en daarna steeds een stapje verder uitbouwen
users
---------
user_id SERIAL PK
username VARCHAR 15
password VARCHAR (32 of 40, als je MD5 of SHA1 gebruikt)
profiel
----------
user_id PK
naam VARCHAR
email VARCHAR
...
...
...
gastenboek
--------------
entry_id SERIAL PK
user_id INT
user_agent VARCHAR
ip INET
vervolgens koppel je door een FK de user ID van profiel aan de user_id van users door een restrict of cascade (CASCADE in dit geval verwijdert dan het profiel van degene als de user account wordt verwijderd).
gastenboek zou ik niet koppelen, misschien wil je de gastenboek entry's bewaren ookal bestaat de user niet meer.
Maak een tabel met daarin al de gegevens van de verschillende gebruikers, zie jouw profiel dwz naam +email + idnummer.
Elke bericht (andere tabel) dat je ontvangt verwijst dan ook naar dit unieke id-nummer.
Als 1 van je gebruikers van email wisselt, hoeft dat maar 1 keer aangepast en alles blijft kloppen als een bus.
hoe kan je ervoor zorgen dat user_id van gastenboek en user_id van users/profiel dat dat goed blijft (als je t niet koppelt)
Per bericht moet wel duidelijk zijn van welke user_id t komt lijkt me?
zoiets als:
userID(gastenboek) == userID(users)
EDIT:
Ben er inmiddels achtergekomen wat MD5/SHA1 inhoud...
Gewijzigd op 01/01/1970 01:00:00 door Tamara
Ik zou de gebruiker geen ID meegeven, is nergens voor nodig, de gebruikersnaam is toch uniek? Dan kan dat een Primary key worden. Dan doe je de gebruikersnaam in 3 tabellen opslaan, in plaats van de ID. Als je er voor zorgt dat je relaties ON UPDATE UPDATE zijn, kan je gebruikersnamen nog makkelijk wijzigen ook.
De berichten in het gastenboek zou ik wel een ID meegeven, aangezien daar niet echt een unieke sleutel te bedenken is. Gebruikersnaam en timestamp zou een idee zijn, maar dat raad ik af (dan kan je in dezelfde seconde geen 2 berichten meer posten).