'The PRIMARY KEY constraint uniquely identifies each record in a database table.'
Dit id identificeert toch niet de rij, maar de user waaraan hij is gekoppeld, waarom is dit dan alsnog een primary key (en niet bijvoorbeeld een unique)?
En primary key is ten alle tijde unique, en daar uit volgend NOT NULL.
Dus je geeft door een kolom een primary key te maken twee constraints; UNIQUE en NOT NULL
Je kunt je afvragen of je in deze context dit in een aparte tabel moet zetten.
Normaal gesproken heb je alleen een één op één relatie tussen tabellen als je kolommen krijgt die vaker niet dan wel een waarde bevatten, of als je om veiligheidsredenen bepaalde informatie gescheiden wilt houden.
Nu heb ik het id van de row en het id van het profiel waar het item aan is gekoppeld samen als primary key, is dit handig of kan ik net zo goed alleen het id van de row als primary key gebruiken, en zo ja; waarom?
Je moet jezelf afvragen of die tabel functioneel is
Want als je voor een user bepaalde vaste gegevens op wilt slaan, kan die net zo goed in 1 tabel opslaan
Ik gebruik deze tabel voor het opslaan van items op de profielen van de gebruikers, dat zijn items die zij zelf kunnen toevoegen, volgens mij kan ik dat niet echt op een andere manier doen.
Wat is het idee erachter? Weleens van het KISAS principe gehoord?
(Ik ook niet verzin het net zelf)
Heeft een gebruiker bepaalde eigenschappen die vast staan, dan sla je die gewoon in de gebruikerstabel op.
Het idee achter de tabel 'user_profile_items' is dat daar items in opgeslagen staan die een gebruiker aan zijn profiel kan toevoegen (Een gebruiker heeft de mogelijkheid stickers, stukjes tekst etc. toe te voegen aan zijn profiel) en in die tabel staan die stickers en stukjes tekst (met de x, y en z as van waar ze op het profiel verschijnen). Het lijkt me niet dat dit in de gebruikerstabel hoort.
