ENUM type in een tabel opnemen (evenals SET) is een inherent slechte optie. Bedenk dat je je tabel structuur moet gaan aanpassen als er een extra optie bijkomt. Gebruik in plaats daarvan een TINYINT met ofwel een extra tabel om de tekst waardes te kunnen joinen, of definieer de tekst waardes in een php bestand. Scheelt je een hoop moeite als je morgen bedenkt dat er nog een extra niveau bij moet komen.
True, ik geef toe dat het niet netjes is.
Maar als je elke wijziging achteraan plaatst, is er toch weinig kans op fouten? Feit is alleen dat je de structuur moet aanpassen bij een nieuwe toevoeging (die ik overigens voor een friend-request-systeem niet zou verwachten)
Er gaat niets mis als je iets toevoegt, maar je database structuur aanpassen omdat je een extra waarde wilt opslaan is wat mij betreft een no-no. Net zo erg als kolommen met nummers gebruiken...
Iets niet verwachten is ook een recept voor fouten. Bij een vrienden systeem kan ik me bijvoorbeeld al voorstellen dat je op zeker moment een gradatie wil instellen voor vrienden ('e_friend', 'real_friend', 'boy_friend') om maar iets te noemen.
Ehh, is het nou wel of niet een goede oplossing?, en hoe laat ik de vrienden dan zien, en hoe laat ik mensen elkaar toevoegen(, blokkeren wordt simpel dan ;))
Aar, jij nodigd mij uit als vriend, ik accepteer dat (natuurlijk ;-)). Dan sta ik wel in jouw vrienden lijst, maar jij niet in de mijne.
Dus de query moet iets uitgebreider:
SELECT FriendID FROM Friends WHERE RequestUserID = 1234 AND Status ='accepted'
UNION
SELECT RequestUserID FROM Friends WHERE FriendID = 1234 AND Status ='accepted'
