[MySQL] Beste opbouw voor een database

[RSD]

Ik zit al lange tijd met wat nu de beste methode is om je database op te bouwen. Er zijn allemaal verschillende normalisaties mogelijk natuurlijk. Ik kan het het beste uitleggen aan de hand van een voorbeeld denk ik. Stel ik heb een tabel user en een tabel media. Nu wil ik hier allerhande queries op uitvoeren. Het gaat om een website waar de user een media bestand kan uploaden. De user en de media zijn dus aan elkaar gekoppeld. Daarnaast kan de user ook reageren op media in de tabel comment. Nu heb ik de volgende mogelijkheden voor de opzet en ik vroeg me af welke het beste is:

user
- userid
- name

media
- mediaid
- title

comment
- commentid
- comment

usermedia
- userid
- mediaid

usercomment
- userid
- commentid

mediacomment
- mediaid
- commentid

of

user
- userid
- name

media
- mediaid
- userid
- title

comment
- commentid
- mediaid
- userid
- comment

Het gaat om een website die redelijk druk bezocht wordt en ik wil de database helemaal op de schop nemen en daarom is de eerste op zet erg belangrijk. Bij de eerste variant zal ik erg veel joins nodig hebben, bij de tweede minder, alleen bij de tweede variant zal soms gezocht moeten worden in grotere datasets. Welke mogelijkheid is het beste?

[HuHu]

Waarom al die koppeltabellen? Kan één media door meerdere users worden geplaatst? Kan één comment door meerdere users worden geplaatst? Dat zijn de vragen die je jezelf moet stellen.

Zo ja: situatie 1.
Zo nee: situatie 2.

[RSD]

Okee, dan heb ik dus situatie 2 nodig ;-) Nog een vraagje. Ik zit ook altijd met de benamingen van de velden.
Stel ik heb een tabel friend en ik moet daar twee keer userid in verwerken. Wat kan ik dan als beste als naam gebruiken voor beide velden. En zoals in de tabel comment wat is dan beter:

comment
- commentid
- commentuserid
- commentsent

of

comment
- id
- userid
- sent

Als ik voor variant twee ga, dan kom ik in de knoop met de consistentie in een tabel waar twee keer userid in voor zou komen. Echter variant 1 scheelt wat typen bij het joinen van tabellen.

[ Voor 5% gewijzigd door RSD op 26-04-2012 15:15 ]

[IceM]

In plaats van userid in tabellen anders dan de tabel user te gebruiken is het misschien makkelijk om een beschrijvende benaming te gebruiken, bijvoorbeeld author_id voor de auteur van een comment, owner_id voor de eigenaar/uploader van een media item, ....

[RSD]

Dan wordt het volgens mij één grote chaos en moet je continue kijken wat je ook alweer gebruikt hebt.

[NMe]

Die friend-tabel zou ik eerder friendship noemen (de tabel definieert de link tussen jou en een vriend, niet de vriend zelf) en de twee user-id's zou ik InitiatingUserId en FriendUserId of iets dergelijks noemen. Je gaat namelijk (neem ik aan) ook een confirmed-veldje nodig hebben waarmee je aangeeft of de vriendschap is bevestigd door de ander, dus het is relevant dat de user in de eerste kolom de vriendschap heeft aangevraagd terwijl de tweede passief was.

IceM schreef op donderdag 26 april 2012 @ 15:16:
In plaats van userid in tabellen anders dan de tabel user te gebruiken is het misschien makkelijk om een beschrijvende benaming te gebruiken, bijvoorbeeld author_id voor de auteur van een comment, owner_id voor de eigenaar/uploader van een media item, ....

Ben ik zelf niet zo'n voorstander van, maar dat is persoonlijk. Als die verduidelijking nodig is, dan gebruik ik in plaats van UserId meestal iets als AuthorUserId.

Verder mag dit topic wel naar Software Engineering & Architecture aangezien het om database-ontwerp gaat.

PRG>>SEA

[ Voor 43% gewijzigd door NMe op 26-04-2012 15:27 ]

[RSD]

In het verleden heb ik al verschillende mogelijkheden voor een friend-gebeuren gemaakt, maar welke optie nu het beste is weet ik niet. Als de vriendschap eenmaal correct bevonden is door de andere partij, kan de degene die de relatie begonnen is ook de vriendschap weer beëindigen. De andere pargtij zou dan als initiating moeten worden aangemerkt. Wat ik dus heb gedaan was het volgende:

user:
- userid
- name

friend
- userid
- frienduserid
- confirmed

Bij een vriendschaps verzoek voeg je twee rijen toe aan de tabel friend met de userid's gekruisd

dus bijv:

userid - frienduserid - confirmed
10 - 20 - 0
20 - 10 - 1

Hierbij is userid=10 de aanvrager, omdat deze de relatie van 20 met 10 al goedgekeurd heeft.

Zo kun je ook makkelijk verzoeken weghalen en als de ene de relatie verbreekt, dan is dat ook mogelijk door simpel de confirmed aan te passen. Nadeel is wel dat je tabel vrij groot kan worden NxN kan worden als ik het goed heb. Maar dan is iedereen een vriend met elkaar. Trouwens confirmed kun je ook een tijd laten zijn, zo weet je altijd wie als eerste was met het aanvagen.

[ Voor 4% gewijzigd door RSD op 26-04-2012 15:45 ]

[HuHu]

Dat tweemaal opnemen zou ik niet doen, dat lijkt me erg foutgevoelig. Ik zou zoiets doen:

userId - otherUserId - userConfirmed - otherConfirmed
10 - 20 - 0 - 1

Als je naar de vriendschappen van iemand zoekt, dan doe je: SELECT ... FROM ... WHERE userId = 10 OR otherId = 10. Maar hier heb ik geen ervaring mee, dus wellicht is er een beter oplossing mogelijk. Dit is wat mij het eerste te binnen schiet.

[RSD]

Jah, maar als je dan moet joinen op die query, gaat dat niet echt makkelijk volgens mij. Of kun je ook doen:

JOIN (...) ON (... OR ...)

[RobIII]

RSD schreef op donderdag 26 april 2012 @ 17:31:
Of kun je ook doen:

JOIN (...) ON (... OR ...)

Doe eens gek en probeer het eens

Komaan, je weet inmiddels donders goed dat we hier niet aan handjes-houden doen en dat we eigen inzet verwachten (en dat je, waar nodig, eerst zorgt dat je de basiskennis onder de knie hebt). Dus sla er eens een boek/website/tutorial/whatever SQL (en normaliseren) op na en ga dan eens proberen iets te bouwen.

[ Voor 13% gewijzigd door RobIII op 26-04-2012 17:47 ]