[MySQL] Advies gevraagd datamodel reactiemodule

[Maghiel]

Ik ben bezig een module te ontwikkelen waar gebruikers mee kunnen reageren. Op deze reacties kunnen dan ook weer gereageerd worden.

Ik sla reacties nu als volgt op:

SQL:

CREATE TABLE IF NOT EXISTS `reactions` (
  `id` int(11) NOT NULL auto_increment,
  `userid` int(11) NOT NULL,
  `userusername` varchar(255) NOT NULL,
  `artistid` int(11) NOT NULL,
  `reaction` text NOT NULL,
  `reactionid` int(11) NOT NULL default '0',
  `timestamp` timestamp NOT NULL default CURRENT_TIMESTAMP,
  `remoteip` varchar(255) NOT NULL,
  PRIMARY KEY  (`id`),
  KEY `userid` (`userid`,`userusername`,`artistid`,`timestamp`),
  KEY `reactionid` (`reactionid`)
);

wanneer reactionid = 0 is het een hoofdreacties, wanneer het een reactie op een reactie is reactionid > 0.

Is het verstandig op deze manier te doen? Of is het misschien slimmer een aparte tabel voor de reacties op reacties te maken en dezen met een JOIN op te halen?

Alvast bedankt!

[SchizoDuckie]

Ik zou inderdaad gewoon een ID_ReactionParent ofzo aanmaken, maar ik zou hem niet reactionid noemen ivm logica: Je zit in een tabel reaction, dat ding heeft een id, en een reactionid. welke id is dan de id van de reactie zelf?

Verder ben ik altijd zeer tegen op 'id' als een eerste veld naam die auto increment is.

Als je jezelf nou aanleert om dat bijv ID_Reactie te noemen, en in alle tabellen waar je daar naartoe linkt deze ook ID_Reactie noemt, dan heb je tenminste een uniek veld in al je queries. (Plus, een database analyse tool kan ook nog eens automagisch je relaties vinden )

[ Voor 10% gewijzigd door SchizoDuckie op 08-02-2008 09:49 ]

[TeeDee]

En wat als je nu een reactie op een reactie op een reactie hebt? Of ga je in je 2e reactie wel gebruik maken van een parent?

Mag ik trouwens vragen waarom je userusername en userid opslaat? Let wel, er kunnen goede redenenen voor redundantie zijn, alleen ga je hier potentieel problemen krijgen (als een username aangepast wordt bijvoorbeeld).

[ Voor 4% gewijzigd door TeeDee op 08-02-2008 09:49 ]

[SchizoDuckie]

TeeDee schreef op vrijdag 08 februari 2008 @ 09:49:
En wat als je nu een reactie op een reactie op een reactie hebt? Of ga je in je 2e reactie wel gebruik maken van een parent?

Het lijkt me dat je alleen maar een parent reactie id meegeeft, een simpel loopje kan de rest onder elkaar nesten zo diep als je wil

[Verwijderd]

Mis ik nu een verwijzing waarop je reageert? of is dat artistid?

SchizoDuckie schreef op vrijdag 08 februari 2008 @ 09:48:
Verder ben ik altijd zeer tegen op 'id' als een eerste veld naam die auto increment is.

Toch is het in de praktijk wel veel makkelijker werken...

Als je jezelf nou aanleert om dat bijv ID_Reactie te noemen, en in alle tabellen waar je daar naartoe linkt deze ook ID_Reactie noemt, dan heb je tenminste een uniek veld in al je queries. (Plus, een database analyse tool kan ook nog eens automagisch je relaties vinden )

Waarom zou je foreign-key relaties opzoeken via naam? Ten eerste heb je toch gewoon foreign-key relaties voor? Ten tweede kan je nooit 2x naar dezelfde tabel verwijzen...

[SchizoDuckie]

Verwijderd schreef op vrijdag 08 februari 2008 @ 10:16:
Mis ik nu een verwijzing waarop je reageert? of is dat artistid?


[...]

Toch is het in de praktijk wel veel makkelijker werken...

Da's onzin, maar dat merk je vanzelf zodra je complexe queries met 4 joins en wat group by's gaat genereren Welke ID gaat de group by vinden in jouw tabelstructuur?
Doe eens een voorbeeld waarin alleen 'id' makkelijker is dan ID_entity ?

Waarom zou je foreign-key relaties opzoeken via naam? Ten eerste heb je toch gewoon foreign-key relaties voor? Ten tweede kan je nooit 2x naar dezelfde tabel verwijzen...

Klopt en klopt. Maar ik hou uit gewoonte ook altijd rekening met de database engines die dat nog niet kennen

[ Voor 4% gewijzigd door SchizoDuckie op 08-02-2008 10:23 ]

[TeeDee]

SchizoDuckie schreef op vrijdag 08 februari 2008 @ 09:57:
[...]


Het lijkt me dat je alleen maar een parent reactie id meegeeft, een simpel loopje kan de rest onder elkaar nesten zo diep als je wil

Dat begrijp ik, maar hou het dan wel gewoon in één tabel. Daar doelde ik op.

[Verwijderd]

SchizoDuckie schreef op vrijdag 08 februari 2008 @ 10:21:
Doe eens een voorbeeld waarin alleen 'id' makkelijker is dan ID_entity ?

Ik bedoelde het voorbeeld dat een id makkelijker werken is als een samengestelde key.

Klopt en klopt. Maar ik hou uit gewoonte ook altijd rekening met de database engines die dat nog niet kennen

Gelukkig hoef ik daar geen rekening mee te houden... werk alleen met MSSQL

[Maghiel]

SchizoDuckie schreef op vrijdag 08 februari 2008 @ 09:48:
Ik zou inderdaad gewoon een ID_ReactionParent ofzo aanmaken, maar ik zou hem niet reactionid noemen ivm logica: Je zit in een tabel reaction, dat ding heeft een id, en een reactionid. welke id is dan de id van de reactie zelf?

Verder ben ik altijd zeer tegen op 'id' als een eerste veld naam die auto increment is.

Als je jezelf nou aanleert om dat bijv ID_Reactie te noemen, en in alle tabellen waar je daar naartoe linkt deze ook ID_Reactie noemt, dan heb je tenminste een uniek veld in al je queries. (Plus, een database analyse tool kan ook nog eens automagisch je relaties vinden )

reactionid is zo genoemd door de structuur van de rest van de database. iets wat uit een tabel reactions komt, heeft een reactionid. iets wat uit tabel artists komt, heeft een artistsid. ik heb dat ook niet bedacht maar moet in dezelfde lijn blijven

id op eerste veld heb ik niets tegen, in een query kun je die zo omnoemen met bv tabelnaam ervoor.

hte is dus ook een uniek veld

TeeDee schreef op vrijdag 08 februari 2008 @ 09:49:
En wat als je nu een reactie op een reactie op een reactie hebt? Of ga je in je 2e reactie wel gebruik maken van een parent?

Mag ik trouwens vragen waarom je userusername en userid opslaat? Let wel, er kunnen goede redenenen voor redundantie zijn, alleen ga je hier potentieel problemen krijgen (als een username aangepast wordt bijvoorbeeld).

dat is nog niet nodig, maar ook met dit model lijkt me dat je gewoon oneindig door kan gaan.
ik gebruik toch ook een parent?

userusername en userid sla ik op zodat ik geen join hoef te doen en dus de snelheid van de website ten goede doe. userusername is bij ons altijd uniek, en kan niet meer verandert worden. net zoals myspace dat doet zeg maar dit heeft een hoop redenen, niet relevant voor dit verhaal. De gebruiker kan iig wel een nickname kiezen, dat is wat anders dan zijn username.

SchizoDuckie schreef op vrijdag 08 februari 2008 @ 09:57:
[...]


Het lijkt me dat je alleen maar een parent reactie id meegeeft, een simpel loopje kan de rest onder elkaar nesten zo diep als je wil

Verwijderd schreef op vrijdag 08 februari 2008 @ 10:16:
Mis ik nu een verwijzing waarop je reageert? of is dat artistid?


[...]


Toch is het in de praktijk wel veel makkelijker werken...


[...]

Waarom zou je foreign-key relaties opzoeken via naam? Ten eerste heb je toch gewoon foreign-key relaties voor? Ten tweede kan je nooit 2x naar dezelfde tabel verwijzen...

idd op artistid. je reageert in dit geval op artiesten.

TeeDee schreef op vrijdag 08 februari 2008 @ 11:11:
[...]

Dat begrijp ik, maar hou het dan wel gewoon in één tabel. Daar doelde ik op.

daar doelde hij ook op toch.


maar goed, niets mis met mijn model in feite dus?

[Verwijderd]

Maghiel schreef op vrijdag 08 februari 2008 @ 21:01:
[...]

userusername en userid sla ik op zodat ik geen join hoef te doen en dus de snelheid van de website ten goede doe. userusername is bij ons altijd uniek, en kan niet meer verandert worden. net zoals myspace dat doet zeg maar dit heeft een hoop redenen, niet relevant voor dit verhaal. De gebruiker kan iig wel een nickname kiezen, dat is wat anders dan zijn username.

Los van je redenering: username en userID opslaan op deze manier is uit den bozen als je ook maar aan enige normaalvorm wilt voldoen.

Wat als een gebruiker zijn naam aanpast? Dan kan je bij elke reactie die hij heeft gezet zijn naam aan gaan passen. En wat als dat bij 1 reactie op wat voor manier dan ook misgaat...dan heeft userID x in die tabel dus 2 verschillende namen.

Met dit soort constructies creeer je zogenaamde invoer, wijzig en verwijder anomalieën...en dat wil je niet .

maar goed, niets mis met mijn model in feite dus?

Wel iets mis dus

[FragFrog]

SchizoDuckie schreef op vrijdag 08 februari 2008 @ 10:21:
Da's onzin, maar dat merk je vanzelf zodra je complexe queries met 4 joins en wat group by's gaat genereren Welke ID gaat de group by vinden in jouw tabelstructuur?
Doe eens een voorbeeld waarin alleen 'id' makkelijker is dan ID_entity ?

SQL:

SELECT  `tableName`.`id` AS `id`
FROM    `tableName`
JOIN    `otherTableName`
  ON    `tableName`.`someId` = `otherTableName`.`id`

etc etc

* FragFrog vindt het juist wel handig altijd een id veld te hebben, heb je tenminste een uniforme unieke ident

Snap ook niet waarom `reaction_ID` handiger zou zijn dan `reaction`.`id` for that matter? Sterker nog, als je een bepaalde view hebt waarvoor je van meerdere tabellen data kan halen wordt het alleen maar veel ingewikkelder als elke tabel een ander uniek id heeft. En het typewerk wat je ermee bespaart spendeer je weer door in je resultset tabelnaam_ID te moeten gebruiken in plaats van id. Ik heb jaren gewerkt op die manier die jij voorstelt, ben blij dat ik dat nu niet meer doe eigenlijk

@ TS: je hebt dus feitelijk een `reaction`.`id` en een `reactionId`. Vind je dat zelf niet ook een klein beetje debiel?

[ Voor 9% gewijzigd door FragFrog op 08-02-2008 23:43 ]

[Webgnome]

FragFrog schreef op vrijdag 08 februari 2008 @ 23:40:
[...]

SQL:

SELECT  `tableName`.`id` AS `id`
FROM    `tableName`
JOIN    `otherTableName`
  ON    `tableName`.`someId` = `otherTableName`.`id`

etc etc

* FragFrog vindt het juist wel handig altijd een id veld te hebben, heb je tenminste een uniforme unieke ident

Snap ook niet waarom `reaction_ID` handiger zou zijn dan `reaction`.`id` for that matter? Sterker nog, als je een bepaalde view hebt waarvoor je van meerdere tabellen data kan halen wordt het alleen maar veel ingewikkelder als elke tabel een ander uniek id heeft. En het typewerk wat je ermee bespaart spendeer je weer door in je resultset tabelnaam_ID te moeten gebruiken in plaats van id. Ik heb jaren gewerkt op die manier die jij voorstelt, ben blij dat ik dat nu niet meer doe eigenlijk

@ TS: je hebt dus feitelijk een `reaction`.`id` en een `reactionId`. Vind je dat zelf niet ook een klein beetje debiel?

Met beide manieren is ansich niks mis. Zullen we het er maar op houden dat er meer wegen naar Rome gaan?

[Maghiel]

Verwijderd schreef op vrijdag 08 februari 2008 @ 23:35:
[...]

Los van je redenering: username en userID opslaan op deze manier is uit den bozen als je ook maar aan enige normaalvorm wilt voldoen.

Wat als een gebruiker zijn naam aanpast? Dan kan je bij elke reactie die hij heeft gezet zijn naam aan gaan passen. En wat als dat bij 1 reactie op wat voor manier dan ook misgaat...dan heeft userID x in die tabel dus 2 verschillende namen.

Met dit soort constructies creeer je zogenaamde invoer, wijzig en verwijder anomalieën...en dat wil je niet .


[...]

Wel iets mis dus

je snapt me nog niet helemaal. de naam die bij de reacties weergegeven wordt is de NICKname, niet de username. er is dus geen probleem als hij zijn naam aanpast. USERname is vast, kan nooit meer verandert worden. basta

FragFrog schreef op vrijdag 08 februari 2008 @ 23:40:
[...]

SQL:

SELECT  `tableName`.`id` AS `id`
FROM    `tableName`
JOIN    `otherTableName`
  ON    `tableName`.`someId` = `otherTableName`.`id`

etc etc

* FragFrog vindt het juist wel handig altijd een id veld te hebben, heb je tenminste een uniforme unieke ident

Snap ook niet waarom `reaction_ID` handiger zou zijn dan `reaction`.`id` for that matter? Sterker nog, als je een bepaalde view hebt waarvoor je van meerdere tabellen data kan halen wordt het alleen maar veel ingewikkelder als elke tabel een ander uniek id heeft. En het typewerk wat je ermee bespaart spendeer je weer door in je resultset tabelnaam_ID te moeten gebruiken in plaats van id. Ik heb jaren gewerkt op die manier die jij voorstelt, ben blij dat ik dat nu niet meer doe eigenlijk

@ TS: je hebt dus feitelijk een `reaction`.`id` en een `reactionId`. Vind je dat zelf niet ook een klein beetje debiel?

njah eigenlijk wel ja. dat ga ik even aanpassen

[Verwijderd]

Maghiel schreef op zaterdag 09 februari 2008 @ 15:39:
[...]


je snapt me nog niet helemaal. de naam die bij de reacties weergegeven wordt is de NICKname, niet de username. er is dus geen probleem als hij zijn naam aanpast. USERname is vast, kan nooit meer verandert worden. basta

Dan nog...een user heeft op 1 moment maar 1 nickname (USERS: ID, Username, Nickname, ...). Niet dat hij bij elke reactie een andere nickname in kan vullen

[FragFrog]

Webgnome schreef op zaterdag 09 februari 2008 @ 00:02:
Met beide manieren is ansich niks mis. Zullen we het er maar op houden dat er meer wegen naar Rome gaan?

Sorry, mijn reactie was niet als rant bedoeld - meer als tegengas voor Schizo's mening dat enkel 'id' niet voldoende is Subtiliteit is zo overrated

Verwijderd schreef op zaterdag 09 februari 2008 @ 16:05:
Dan nog...een user heeft op 1 moment maar 1 nickname (USERS: ID, Username, Nickname, ...). Niet dat hij bij elke reactie een andere nickname in kan vullen

En waarom zou dat niet zo moeten zijn? Alleen maar omdat 'de rest' het zo doet is geen reden het zelf ook zo te doen.

* FragFrog is groot voorstander van zelf nadenken over wat voor functionaliteit je je gebruikers wilt geven

[Verwijderd]

FragFrog schreef op zaterdag 09 februari 2008 @ 16:21:
[...]

En waarom zou dat niet zo moeten zijn? Alleen maar omdat 'de rest' het zo doet is geen reden het zelf ook zo te doen.

* FragFrog is groot voorstander van zelf nadenken over wat voor functionaliteit je je gebruikers wilt geven

Uniek zijn is niet altijd beter.

Het lijkt mij persoonlijk gewoon heel onlogisch om één gebruiker onder meerdere namen tegelijk reacties te kunnen laten geven.

Dat het een optie is, dat je het in je systeem wilt inbouwen en dat het technisch gezien corrent is klopt allemaal...maar ik vind het gewoon een vreemde constructie .

[FragFrog]

Verwijderd schreef op zaterdag 09 februari 2008 @ 16:35:
Het lijkt mij persoonlijk gewoon heel onlogisch om één gebruiker onder meerdere namen tegelijk reacties te kunnen laten geven.

Natuurlijk, mij in eerste instantie ook, maar dat is ook logisch als je bedenkt dat ik al zowat tien jaar op allerhande fora kom en nooit mijn naam bij een post kan veranderen.

Maar dan bedenk ik me weer dat het op het razend populaire 4chan bijvoorbeeld weer wel mogelijk is elke post onder een andere gebruikersnaam te maken. Sterker nog, mijn eigen blog onthoudt de naam waarmee je voor het laatst gecomment hebt, maar geeft je ook de mogelijkheid die altijd te veranderen. Het is een stukje oervrijheid die vroeger heel gewoon was maar de laatste jaren steeds meer in het gedrang komt door sites die je maar verplichten te registreren.

Overigens ga ik er dan wel vanuit dat het hier inderdaad om de mogelijkheid geven tot gaat, niet om de ontwerpfout dat in plaats van een userId een gebruikersnaam gebruikt wordt om gebruiker aan post te koppelen

[Verwijderd]

FragFrog schreef op zaterdag 09 februari 2008 @ 20:11:
[...]

Maar dan bedenk ik me weer dat het op het razend populaire 4chan bijvoorbeeld weer wel mogelijk is elke post onder een andere gebruikersnaam te maken. Sterker nog, mijn eigen blog onthoudt de naam waarmee je voor het laatst gecomment hebt, maar geeft je ook de mogelijkheid die altijd te veranderen. Het is een stukje oervrijheid die vroeger heel gewoon was maar de laatste jaren steeds meer in het gedrang komt door sites die je maar verplichten te registreren.

Klopt, maar daar heb je ook niet echt een "vaste" username/userid combinatie voor jou persoonlijk...en dat is denk ik het verschil. OF je kiest voor 1 ID, 1 inlognaam en 1 schermnaam...of je kiest voor een willekeurige naam per bericht.

Het kan best samen gebruikt worden, alleen zie ik er dan het nut niet van in. Of je moet andere user-based diensten op diezelfde site aanbieden, maar je wilt wel dat men reacties "anoniem" kan plaatsen.

[ Voor 11% gewijzigd door Verwijderd op 10-02-2008 12:59 ]