[MySQL] Advies gevraagd datamodel 1-naar-veel-relatie

[Maghiel]

Ben ik weer

Situatie is als volgt:

Tabel met gebruikers, laten we het even simpel houden:

MySQL:

 CREATE TABLE `users` (
`id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`name` VARCHAR( 255 ) NOT NULL
)

Deze gebruikers moeten vrienden van elkaar kunnen worden.
Hoe ga ik dat nu opslaan?

Zou bijvoorbeeld zo kunnen:

MySQL:

 CREATE TABLE `users_friends` (
`id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`userid` INT NOT NULL ,
`friend_userid` INT NOT NULL ,
INDEX ( `userid` , `friend_userid` )
) 

En dan elke vriend los opslaan. Maar bij veel gebruikers en veel vrienden wordt de tabel dan wel erg groot.

Het zo ook zo kunnen:

MySQL:

CREATE TABLE IF NOT EXISTS `users_friends` (
  `id` int(11) NOT NULL auto_increment,
  `userid` int(11) NOT NULL,
  `friend_userids` text NOT NULL,
  PRIMARY KEY  (`id`),
  KEY `userid` (`userid`)
) 

en dan alle vriendjes ids als een CSV opslaan, en later data ophalen met FIND_IN_SET()
Maar ja een text veld is dan weer niet te indexeren.

SET datatype is dan weer geen optie omdat het maar 64(?) waarden kan bevatten, en ook niet echt flexibel is.

Iemand een idee hierover?

[DJ Buzzz]

De grootte van de tabel in de eerste oplossing is absoluut geen probleem en dit is dan ook volgens mij de beste manier om het op te lossen. De tweede manier is een nogal ranzige oplossing die ook niet echt lekker cross database is.

[BCC]

De eerste is ook enorm veel sneller dan de tweede.

[KoW]

Ik zou ook de eerste oplossing aanhouden.
Als een van de personen uit de lijst verdwijnt dan moeten al zijn "friend" relaties ook vervallen. In de eerste oplossing is dat gewoon SQL, in de tweede oplossing is dat erg rommelig.

Uberhaupt is het lastig om je crossreferences in de gaten te houden.
Hoe geef je aan bij oplossing 2 dat A een vriend is van B en andersom ?
En at dan als die vriendschap wordt verbroken? Of hou je de mogelijkheid open dat persoon A B wel als vriend ziet, maar andersom niet ?

[Maghiel]

DJ Buzzz schreef op zondag 10 februari 2008 @ 13:21:
De grootte van de tabel in de eerste oplossing is absoluut geen probleem en dit is dan ook volgens mij de beste manier om het op te lossen. De tweede manier is een nogal ranzige oplossing die ook niet echt lekker cross database is.

duidelijk

BCC schreef op zondag 10 februari 2008 @ 13:30:
De eerste is ook enorm veel sneller dan de tweede.

duidelijk

KoW schreef op zondag 10 februari 2008 @ 13:33:
Ik zou ook de eerste oplossing aanhouden.
Als een van de personen uit de lijst verdwijnt dan moeten al zijn "friend" relaties ook vervallen. In de eerste oplossing is dat gewoon SQL, in de tweede oplossing is dat erg rommelig.

Uberhaupt is het lastig om je crossreferences in de gaten te houden.
Hoe geef je aan bij oplossing 2 dat A een vriend is van B en andersom ?
En at dan als die vriendschap wordt verbroken? Of hou je de mogelijkheid open dat persoon A B wel als vriend ziet, maar andersom niet ?

had ik inderdaad nog niet goed over nagedacht, wilde d'r net over posten eigenlijk.
Personen zijn altijd vrienden van elkaar.
Daar zit ik dan bij de oplossing 1 ook nog even over na te denken. Ga ik zowel A - B en B - A opslaan?

[BCC]

Bij optie 2 is het bijv. heel naar om vrienden van vrienden op te vragen, terwijl het bij de eerste simpelweg een extra left join is.

[KoW]

Dat is een beetje hetzelfde probleem waar ik mee zit in mijn TeamA TeamB verhaal van een tijdje terug.

Als je alleen A - B opslaat dan heb je een query op 2 kolommen.
En je moet in je logica altijd controleren of je niet alleen A - B al eens hebt opgeslagen, maar ook of B - A misschien al bestaat.

[Maghiel]

KoW schreef op zondag 10 februari 2008 @ 13:43:
Dat is een beetje hetzelfde probleem waar ik mee zit in mijn TeamA TeamB verhaal van een tijdje terug.

Als je alleen A - B opslaat dan heb je een query op 2 kolommen.
En je moet in je logica altijd controleren of je niet alleen A - B al eens hebt opgeslagen, maar ook of B - A misschien al bestaat.

Sommige simpele dingen kunnen soms zo complex zijn

Jij hebt er uiteindelijk voor gekozen A - B en B - A op te slaan? Is inderdaad wel slimmer.

edit:

Ik kan je topic zo snel niet vinden, heb je toevallig een linkje?

[ Voor 7% gewijzigd door Maghiel op 10-02-2008 13:49 ]

[KoW]

Eh, \[.NET Linq] Recursive query op objecten
Het is alleen niet echt vergelijkbaar omdat de koppeling tussen A en B zelf ook iets voorstelt. Dat is in jouw geval niet zo.

[RobIII]

Waar hoort mijn topic?
Dit is meer wat voor SEA

[BCC]

KoW schreef op zondag 10 februari 2008 @ 13:43:
Dat is een beetje hetzelfde probleem waar ik mee zit in mijn TeamA TeamB verhaal van een tijdje terug.

Als je alleen A - B opslaat dan heb je een query op 2 kolommen.
En je moet in je logica altijd controleren of je niet alleen A - B al eens hebt opgeslagen, maar ook of B - A misschien al bestaat.

Dat kun je toch eenvoudig in je model laag oplossen?

[Maghiel]

RobIII schreef op zondag 10 februari 2008 @ 14:04:
Waar hoort mijn topic?
Dit is meer wat voor SEA

scuza

BCC schreef op zondag 10 februari 2008 @ 14:11:
[...]

Dat kun je toch eenvoudig in je model laag oplossen?

explain

[ACM]

BCC schreef op zondag 10 februari 2008 @ 14:11:
Dat kun je toch eenvoudig in je model laag oplossen?

Inderdaad, als je geen bijzondere betekenis aan de volgorde geeft, dan kan je gewoon bij het inserten altijd het laagste userid als A en het hoogste als B beschouwen. Op die manier hoef je nooit te checken of B-A er al is, want die zou door die sortering al A-B geworden zijn de vorige keer.
Anderzijds is de check op B-A vs A-B nou ook weer niet zo vreselijk moeilijk, dus dat bij een insert even checken is ook niet zo erg lijkt me.

Constructies met opslaan van lijsten van id's als csv en dergelijke zou ik niet aan beginnen. Zodra je tegen performanceproblemen met de eerste oplossing aan begint te lopen wordt het interessant te kijken wat de meest voorkomende toegangspatronen zijn, maar tot die tijd zou ik gewoon de simpelste oplossing aanhouden

[Maghiel]

ACM schreef op zondag 10 februari 2008 @ 14:18:
[...]

Inderdaad, als je geen bijzondere betekenis aan de volgorde geeft, dan kan je gewoon bij het inserten altijd het laagste userid als A en het hoogste als B beschouwen. Op die manier hoef je nooit te checken of B-A er al is, want die zou door die sortering al A-B geworden zijn de vorige keer.
Anderzijds is de check op B-A vs A-B nou ook weer niet zo vreselijk moeilijk, dus dat bij een insert even checken is ook niet zo erg lijkt me.

Constructies met opslaan van lijsten van id's als csv en dergelijke zou ik niet aan beginnen. Zodra je tegen performanceproblemen met de eerste oplossing aan begint te lopen wordt het interessant te kijken wat de meest voorkomende toegangspatronen zijn, maar tot die tijd zou ik gewoon de simpelste oplossing aanhouden

opzich worden bij alleen A - B de queries wel weer lastiger. Want wat als ik van B alle vrienden wil weten? Dan moet ik dus op de eerste én de tweede colomn zoeken.

[BCC]

Maghiel schreef op zondag 10 februari 2008 @ 14:22:
[...]
opzich worden bij alleen A - B de queries wel weer lastiger. Want wat als ik van B alle vrienden wil weten? Dan moet ik dus op de eerste én de tweede colomn zoeken.

Dat is een vrij simpele OR.

[Maghiel]

BCC schreef op zondag 10 februari 2008 @ 15:29:
[...]

Dat is een vrij simpele OR.

misschien niet helemaal goed opgeschreven wat ik bedoel(heb ik wel vaker last van ). het is dan toch weer een extra operatie die uitgevoerd moet worden. en als je dan van userid OR friend_userid pakt, kun je ook weer dubbel krijgen, wat je dan weer uit moet filteren, etc

[BCC]

Maghiel schreef op zondag 10 februari 2008 @ 22:53:
[...]
misschien niet helemaal goed opgeschreven wat ik bedoel(heb ik wel vaker last van ). het is dan toch weer een extra operatie die uitgevoerd moet worden. en als je dan van userid OR friend_userid pakt, kun je ook weer dubbel krijgen, wat je dan weer uit moet filteren, etc

GROUP BY userid,friend_userid

[ACM]

Maghiel schreef op zondag 10 februari 2008 @ 14:22:
opzich worden bij alleen A - B de queries wel weer lastiger. Want wat als ik van B alle vrienden wil weten? Dan moet ik dus op de eerste én de tweede colomn zoeken.

Tenzij je alles dubbel op gaat slaan moet je dat toch wel.

Maghiel schreef op zondag 10 februari 2008 @ 22:53:
kun je ook weer dubbel krijgen, wat je dan weer uit moet filteren, etc

Dan doe je het niet goed. Mijn opmerking sloeg er juist op dat je elke combinatie A-B altijd beide kanten op uniek is omdat de variant B-A niet in je tabel kan bestaan.

Dus je moet inderdaad als je alle vrienden van B wilt weten zowel de userid als de frienduserid bekijken, maar je kan er geen dubbelen uit krijgen (uiteraard alleen als je dat afdwingt).

[Maghiel]

ACM schreef op maandag 11 februari 2008 @ 08:54:
[...]

Tenzij je alles dubbel op gaat slaan moet je dat toch wel.


[...]

Dan doe je het niet goed. Mijn opmerking sloeg er juist op dat je elke combinatie A-B altijd beide kanten op uniek is omdat de variant B-A niet in je tabel kan bestaan.

Dus je moet inderdaad als je alle vrienden van B wilt weten zowel de userid als de frienduserid bekijken, maar je kan er geen dubbelen uit krijgen (uiteraard alleen als je dat afdwingt).

zondagavond, veel bier

dank jullie voor de tips!