[sql] Hoe normaliseren bij twee tabellen?

[StephanVierkant]

Ik heb op mijn website de mogelijkheid ingebouwd dat men kan reageren op mijn weblog en op mijn foto's. Ik heb dus als het ware 3 tabellen (versimpeld):

- weblog
- foto
- comments

Momenteel heb ik in de tabel 'comments' een veld die als waarde bijvoorbeeld 'f_1' of 'w_1' (knappe koppen gokten het vast al goed: 'f_1' verwijst natuurlijk naar foto nummer is, 'w_1' naar weblog-artikel nummer 1). Ik heb het idee dat dit verre van ideaal is in meerdere opzichten, maar zou zo niet weten hoe het beter moet.

Wat is in zo'n geval een beter oplossing?

[ Voor 3% gewijzigd door StephanVierkant op 17-12-2008 17:14 ]

[RobIII]

Je stopt nu in 1 veld appels en peren (namelijk f_1 en w_1). Waarom niet gewoon 2 velden waarbij beide nullable zijn? En dan vul je, afhankelijk van waar de comment aan hangt, dus veld A of veld B.

En wat Tofu hieronder zegt kan ook; dan moet je alleen bij een join altijd 2 voorwaarden opgeven; namelijk het type en het id; daarbij kun je geen foreign key constraints gebruiken/afdwingen op het veld waarin je de ID's opslaat omdat er nog steeds appelid's en perenid's in 1 veld staan.

Nog een optie is om een fotocomments en een weblogcomments tabel te maken; dus voor ieder soort comments een eigen tabel.

[ Voor 81% gewijzigd door RobIII op 17-12-2008 17:22 ]

[Tofu]

Comments 2 velden geven:
"type" en "verwijs_id".
Type geef je dan 'f' of 'w' (of 0 of 1 oid)
verwijs_id geef je dan de id van je weblog of foto.

[djluc]

Ik zou dan sowieso 2 kolommen gebruiken. Dus:

weblog_id
foto_id
In je comments table.

Dan kan je lekker simpel joinen. Daarnaast kan je ook dubbele links leggen zoals een comment wat bij een foto hoort welke ook bij een weblog hoort indien gewenst.

[Helmet]

Wat nu als je zo wel een posting als een foto als "content" ziet. Dan heb je enigszinds versimpeld het volgende idee:


id, contenttype, data
1 1 "dit is een blog post blabla"
2 2 "images/data/photo23.jpg"
3 2 "images/data/photo2.jpg"

vervolgens kun je de comments op het id van de betreffende content bekijken.

id, contentid, comment
1, 1, "Dit is een comment op je blog post"
2, 3, "Dit is een comment op je photo2.jpg"
3, 2, "Dit is een comment op photo23.jpg"

Als je bij een bepaald content-type extra velden of informatie nodig zou hebben zou je op basis van contenttype een aantal velden aan kunnen maken:

id, contentid, info, data
1, 2, 'rating', 'Dit is een extra veld voor het type foto'
1, 1, 'track-back', 'Dit is een extra veld voor je \'blog\' content type'

Het geheel is wel wat complexer, maar het biedt je zeker meer flexibiliteit

[StephanVierkant]

Bedankt voor de reacties. Ik denk dat ik de oplossing van Tofu ga gebruiken, de andere oplossingen zijn wat lastiger omdat de gegeven database natuurlijk iets versimpeld is: ik heb ook foto-albums, andere bijzondere velden voor het weblog, etc.

[RobIII]

Helmet schreef op woensdag 17 december 2008 @ 17:23:
Het geheel is wel wat complexer, maar het biedt je zeker meer flexibiliteit

Het is niet alleen complexer, je zit een database-in-een-database te bouwen en dat is per definitie gedoemd te mislukken en is meer dan eens besproken hier Die flexibiliteit houdt ook héél snel op.

[.oisyn]

Ik vind Helmet's oplossing wel aardig, met uitzondering van de laatste tabel waarin ie imho veel te ver door normaliseert. Voor het ophalen van de laatste 10 blogentries bijvoorbeeld heb je dan al joins nodig, om nog maar te zwijgen over de data processing aan de client kant om alle data bij elkaar te krijgen.

Ik zou zijn eerste tabel dan ook ontdoen van 'data', de derde tabel geheel weggooien, en daarnaast gewoon je oorspronkelijke foto en weblog tabellen behouden. Wat je dan bereikt hebt is in feite dat de id space van alle losse tabellen geshared wordt, en dat je derhalve makkelijk foreign key constraints kunt leggen zonder in je comments tabel een id te hoeven hebben voor elk element waar je mogelijk comments aan kunt toevoegen (nu zijn dat er twee, maar wat als je naast blogs en foto's bijvoorbeeld ook reviews en nieuwsitems e.d. toe gaat voegen?).

Samenvattend:

content
- id: int, primary
- type: enum { weblog, foto } (optioneel, wellicht wel handig)

weblog
- id: int, primary, foreign(content)
- etc...

foto
- id: int, primary, foreign(content)
- etc...

comments
- id: int, primary
- content_id: int, foreign(content)
- etc...

[ Voor 24% gewijzigd door .oisyn op 17-12-2008 17:50 ]

[? ?]

..

[ Voor 103% gewijzigd door ? ? op 25-01-2013 09:51 ]