[Databases] ontwerp van users

[Zoolander]

Hallo,

Ik ben bezig met een DB te maken.
Het is voor een programma waarbij users elkaar kunnen beoordelen je maar 1 keer een user mag beoordelen. Om dat bij te houden kan ik enkel de volgende oplossing verzinnen:

Per user maak je een tabel aan met een veld dat heet username. Op deze manier kan je precies zien welke user al wel of niet iets voor die persoon heeft ingevult. Maar, het nadeel hiervan vind ikzelf: als je 400 users hebt, krijg je ook 400 tabellen!

Is dat ongebruikelijk bij databases of wordt dit wel vaker zo gedaan?

Alvast dank! (ps. goed boek over DBontwerp waar dit soort issues instaan is ook welkom)

[WhizzCat]

Tabel 'users' met daarin de bijbehorende velden lijkt me logischer...

edit: met de bijbehoren prim. key (id en username ofzo)

Zoek eens naar boeken van Academic Service (Korpershoek is de schrijver dan geloof ik) die lui hebben altijd erg goeie boeken

[ Voor 16% gewijzigd door WhizzCat op 02-11-2003 16:45 ]

[Mithrandir]

Wat de topicstarter wil is niet goed.

Je wilt een veel-op-veel oplossing. Daarom moet je een koppeltabel maken:

een tabel users met username (userid gebruik ik altijd)
een koppeltabel:

code:

[beoordelingen]
userid, otheruserid

[users]
userid, username, email, etc

Met andere woorden: je maakt een tabel waarin in de eerste column de username staat van de 'beoordeler' en in de tweede column die van de beoordeelde.

[ Voor 7% gewijzigd door Mithrandir op 02-11-2003 16:47 ]

[SinergyX]

1 tabel maken (votes ofzo) waarin de user staat die foto en de user wie hij vote. (beide id ofzo).
Dan als iemand gaat voten, een simpele query loslaten om te kijken of die persoon al had gevote op die persoon.
Verder dan idd zoals boven stond, id gekoppeld aan een andere tabel waar alle userinfo instaat.

[ Voor 19% gewijzigd door SinergyX op 02-11-2003 16:48 ]

[Sybr_E-N]

Jij moet je zeker even verdiepen in de database materie.

Het lijkt mij handiger om 1 tabel met usernamen met aanverwante dingen zoals geboortedatum, email adres enzo te hebben. En 1 koppeltabel waarin bij houd wie op wie heeft gereageerd. Daarin sla je de user nummer (cq user_id) op en nog een kolom als gereageerd op (reactedon_id, ik verzin maar wat namen hoor ). Maak deze cominatie uniek, zodat ze maar 1 keer voor kunnen komen, en dan heb je wat jij hebben wilt.

edit:

ik moet sneller typen.

[ Voor 5% gewijzigd door Sybr_E-N op 02-11-2003 16:51 ]

[Mithrandir]

Sybr_E-N schreef op 02 november 2003 @ 16:50:
[....]

edit:

ik moet sneller typen.

offtopic:
Heb ik ook altijd last van

[Zoolander]

Ik ben op de hoogte van koppeltabellen en samengestelde sleutes, referentiele integriteit, maar ben op zoek naar een flexibele oplossing.
Wellicht dat oplossingen boven mogelijk zijn, maar kan ik dan:

... Zien wie wat voor vote heeft uitgebracht (kan een getal van 1 / 10 zijn)
... Bepaalde mensen krijgen een rol, en kunnen met die rol onder dezelfde username meerdere keren voten.
... de vote gaat niet over een persoon, maar over een eigenschap van een persoon. Dus 1 persoon moet bijvoorbeeld 5 keer een vote over iemand uitspreken. (behendigheid, samenwerken, inzicht, verzin ze maar)

Wellicht dat de complexheid van mijn probleem duidelijker wordt.
Ik begrijp iig dat niemand per user een tabel een strak plan vind?

[RobIII]

* RobIII maakt wel effe een voorbeeldje van wat je wil Hang in there



Uitleg:

tbl_Users bevat gebruikers (naam, adres, email, whatever):

tbl_UserProperties bevat properties waarop je kunt voten:

code:

up_id up_desc
===== =======
1     Behendigheid
2     Samenwerken
3     Inzicht
..    ....
..    ....

tbl_Uservotes bevat de votes (datum, score etc):
uv_us_id = user die gestemd heeft
uv_voted_us_id = gebruiker waarop gestemd is
uv_up_id = property waarop gestemd is
uv_score = de score voor dat property
uv_date = datum waarop die stem is uitgebracht

Natuurlijk is dit simpel uit te breiden met meer velden in de tabellen etc, maar zo moet het lukken. Een mooi voorbeeld is dat je nu heel makkelijk een eigenschap "Collegialiteit" kunt toevoegen door in je tabel tbl_UserProperties een extra record aan te maken. Vervolgens kun je zonder wijzigingen in je software ook daar op gaan voten (mits je dus die properties ook uit die tabel leest en niet hard-coded in je software zet).

/Slotje

[ Voor 106% gewijzigd door RobIII op 02-11-2003 17:23 ]

[Zoolander]

how cool!
Zit hier echt mee te tobben. Relationele databases is erg leuk, maar ook best complex zo nu en dan. (boek wat je alles verteld nog steeds welkom )

thanx!

[Verwijderd]

Als je een tabel maakt met de volgende dingen moet het wel lukken denk ik:

Userid_Voter
Userid_Person (dat is dus die waarop je vote)
Eigenschap_id (een id van de eigenschap waarop je vote)
Vote (het getal)

de eerste 3 attributen is de primary key... zo moet het toch wel lukken of niet?

[Zoolander]

En hoe dwing ik netjes referentionele integriteit af op de usernames?
want die komen uit 1 tabel....
Of vind je dat onzin, en moet ik dat codebased doen?

En waarom is het eigelijk zo slecht om per user een tabel aan te maken?
Dan krijg ik wel veel 1 op veel relaties met de oorspronkelijke tabel waar username, password, email, etc in staan, maar is het wel opgelost....
of niet?

[ Voor 43% gewijzigd door Zoolander op 02-11-2003 17:21 ]

[RobIII]

Zoolander schreef op 02 november 2003 @ 17:18:
En hoe dwing ik netjes referentionele integriteit af op de usernames?
want die komen uit 1 tabel....
Of vind je dat onzin, en moet ik dat codebased doen?

Zie mijn "diagram". Daarin is de referentiële integriteit 100% afgedwongen

[ Voor 4% gewijzigd door RobIII op 02-11-2003 17:20 ]

[Mithrandir]

Zoolander schreef op 02 november 2003 @ 17:18:
En hoe dwing ik netjes referentionele integriteit af op de usernames?
want die komen uit 1 tabel....
Of vind je dat onzin, en moet ik dat codebased doen?

Unique field? (en rob had gelijk)

[ Voor 4% gewijzigd door Mithrandir op 02-11-2003 17:23 ]

[The Eagle]

Zoolander schreef op 02 november 2003 @ 17:11:
Relationele databases is erg leuk, maar ook best complex zo nu en dan.

Vertel mij wat...ik werk met een ERP systeem dat ruim 6000 tabellen heeft die allemaal aan elkaar gekopeld zijn. Ga dan maar eens zoeken als er ergens een foutje zit......

[Zoolander]

Kan je vanuit 1 tabel met twee velden een relatie leggen naar een andere tabel met maar 1 veld? Dacht dat dit nooit kon, zo wel mooi zijn, maar krijg altijd error als ik dat in MySQL probeer.

Klopt dat?

BTW wel erg bedankt voor je voorbeeld. Maar bij mij geeft ie een error als ik die twee usernames will koppelen aan de tabel waar alle usergegevens instaan....

[ Voor 29% gewijzigd door Zoolander op 02-11-2003 17:30 ]

[Verwijderd]

RobIII schreef op 02 november 2003 @ 17:20:
[...]

Zie mijn "diagram". Daarin is de referentiële integriteit 100% afgedwongen

zo had ik het dus ook in gedachte... alleen heb ik het niet zo uitgebreid gemaakt als jij

[RobIII]

Zoolander schreef op 02 november 2003 @ 17:24:
Kan je vanuit 1 tabel met twee velden een relatie leggen naar een andere tabel met maar 1 veld? Dacht dat dit nooit kon, zo wel mooi zijn, maar krijg altijd error als ik dat in MySQL probeer.

Klopt dat?

Tja...Ik heb geen flauw idee wat MySQL hier van bakt. IMHO is MySQL een nogal "sorry excuse for a database", maar dat staat hier niet te discussie. In een "normale","fatsoenlijke" of hoe je het ook noemen wil, Referentiële database moet dit in ieder geval kunnen.

[Zoolander]

Ok.
Wat adviseer je mij te nemen voor DB dan? Sta open voor nieuwe tools!
Zolang het maar met PHP werkt, SQL praat (duh) en niet heeeel veeeel geld kost.

[RobIII]

MSDE is de Microsoft Data Engine. Gewoon SQL Server 2000 dus, maar dan gratis en een paar kleine dingetjes eruit gesloopt _{effe uit het blote bolleke}:

* Max 2Gb data files
* Max. 5 users (hoewel ik zelden problemen ondervind met 20+ users)
* Geen replication (who cares )

Meer over de limitaties vind je hier

Lees wel effe de Appropriate uses of MSDE FAQ enzo.

Daar zou ik voor gaan iig.

[ Voor 16% gewijzigd door RobIII op 02-11-2003 17:45 ]

[Zoolander]

Als het mijn probleem oplost, ga ik daar zeker voor,
alleen: heeft ook goede wysiwigtools zoals mysql SQLyog en PHPmyAdmin heeft?

[RobIII]

Zoolander schreef op 02 november 2003 @ 17:44:
Als het mijn probleem oplost, ga ik daar zeker voor,
alleen: heeft ook goede wysiwigtools zoals mysql SQLyog en PHPmyAdmin heeft?

Ja, sorry hoor. Maar moeten we nu alles voorkauwen of ga je zelf nog effe googlen?

Er zijn zat goede wysiwigtools voor MSDE, hoewel ik ga voor de SQL Analyzer en Enterprise manager die bij de grote broer van MSDE zitten. Voor de rest: zie de links in mijn vorige post.

[ Voor 5% gewijzigd door RobIII op 02-11-2003 17:48 ]

[Zoolander]

hehe, je hebt gelijk.
Dat zal ik met MSDE ff doen. Maar het is zoveel werk als je ALLES in je omgeving op PHP/MySQL hebt afgestemd al die resources opnieuw te moeten zoeken.
Terwijl ik bij het antwoord NEE niet eens naar MSDE omgekenen had, want SQL intikken om relaties te leggen en tabellen te beheren is beetje uit de tijd vind ik. (mijn mening)

Heel erg bedankt voor je hulp. Ik ga weer op pad!

THANX!

[JaQ]

Zoolander schreef op 02 november 2003 @ 17:24:
Kan je vanuit 1 tabel met twee velden een relatie leggen naar een andere tabel met maar 1 veld? Dacht dat dit nooit kon, zo wel mooi zijn, maar krijg altijd error als ik dat in MySQL probeer.

Klopt dat?

Een relatie leggen van 2 velden naar 1 veld? hoe wil je dat in godsnaam doen?

(tabel_1.kolom_1, tabel_1.kolom_2) = tabel_2.kolom_1 ???

dat is toch onzin? zie je zelf ook toch wel?

Anywayz.. je kan wel een foreign key leggen in MySQL (van 1 kolom in 1 tabel naar 1 kolom in 1 tabel), maar die wordt toch niet gecontroleerd oid., is dus alleen leuk om later gemakkelijk een grafische weergave van de databasemodel te kunnen genereren. MySQL kent geen procedural language, dus geen echte foreign keys.

[Zoolander]

Hmm, daar ben ik het niet mee eens.
In MySQL met datatype INNO DB controleerd ie wel degelijk child/ partent relaties. Je kan echt geen rare waarde ergens invullen als er een foreign key opstaat. Tevens werkt ON DELETE en ON UPDATE (cascade, no action, set null, ...) ook zeer goed bij MySQL (ver 4.x.x) als je maar INNO DB gebruikt.

Maar waarom ben je zo zeker van die relaties, dat die niet kunnen? (ik dacht het ook hoor, zoals je in mijn quote die je gebrukt kan zien) Volgens jou kan je zowel in MySQL als in MSDE of wathever geen 2 velden naar 1 veld laten verijwen zoals ROBIII dat doet?

Ben heel benieuwd.

[ Voor 7% gewijzigd door Zoolander op 02-11-2003 18:39 ]