[Mysql] chiave unica su due campi

[Nunkij]

Salve a tutti.
Devo realizzare uno script che gestisca una lista amici.
Nel database ho una tabella utenti e una tabella amici.
La tabella amici ha due campi numerici in cui metto gli id dei due amici a ogni riga.

id_mittenteRichiesta, id_destinatarioRichiesta

Fin qui tutto ok!

Ho creato due chiavi uniche sui due campi che mi impedisca di avere richieste ripetute.

C'è il modo di avere un controllo che mi impedisca di avere questa situazione?

id_mittenteRichiesta, id_destinatarioRichiesta
12, 13
13,12

Di fatto sarebbe la stessa "amicizia" e quindi non devo consentirlo!
Ovviamente questa cosa posso gestirla da php, prima della query, ma ero curioso di sapere se un database basato su sql potesse gestire una cosa simile.

Ovviamente se l'idea di base è sbagliata e qualcuno volesse suggerirne una sua accetto consiglie critiche!

Grazie a chi mi risponderà


ps: ho tralasciato tutti i dettagli sullo status dell'amicizia che può essere approvata, bloccata, ecc... ma sono stati implementati.

[badaze]

Fossi in te non cercherei di mettere un controllo. Ecco perché.

Con il tuo sistema devi, per ritrovare tutti gli amici di 13, mettere : mittente = 13 or destinatario = 13. Il che se hai moltissimi record non sarà ottimo.
Mentre se non fai controlli visto che hai un indice sul mittente la lettura dei dati sarà quella giusta.

Sempre con il tuo sistema per ricavare gli amici di 13 dovrai rendere più complessa la query:
select case when mittente = 13 then destinatario else mittente end as amici
from tabella where mittente = 13 or destinatario = 13

Mentre con l'altro :
select destinatario from tabella where mittente = 13 or destinatario = 13

[Nunkij]

ma se non metto un controllo non rischio che le richieste di amicizia si incrocino tra loro? Lo consideriamo un rischio accettabile per incrementare le prestazioni?

In realtà per fare le liste di amici mi sono semplicemente affidato da una buona UNION. Non è più intuitivo?

[clasku]

secondo me il controllo lo fai a programma non nella query
quando mostri i dati ad un utente gli metti i dati dei destinatari delle richieste che ha fatto e quelli dei mittenti che gliela hanno chiesta. in base a questo gli consenti di chiedere l'amicizia solo a chi non gliela ha ancora chiesta

e quando un destinatario accetta la richiesta, cancella il record

le amicizie definite tra utenti le tieni in un'altra tabella

[badaze]

ma se non metto un controllo non rischio che le richieste di amicizia si incrocino tra loro? Lo consideriamo un rischio accettabile per incrementare le prestazioni?

In realtà per fare le liste di amici mi sono semplicemente affidato da una buona UNION. Non è più intuitivo?

Oooppss. Non avevo capito. Avevo pure letto richiesta ma avevo capito amicizia.

Comunque. Come l'ha scritto clasku lo puoi fare a livello di programma. Potresti anche farlo con una stored procedure ma in questo caso, penso che se 12 richiede amicizia con 13 e che 13 ha già fatto la richiesta a 12 sarebbe bene informare 12 che 13 ha fatto la richiesta.

Quindi durante il controllo, controlli che il mittente della richiesta non sia già presente nella tabella come destinatario di una richiesta fatta dal destinatario della richiesta.

Per le liste di amici non capisco l'uso della UNION. Puoi spiegare ?

[Nunkij]

In pratica ho fatto una cosa simile.
Se voglio sapere tutti gli amici di 13 faccio così:

Select IdUtente
From tbAmici
Where idMittente = 13
UNION
Select Nome
From tbAmici
Where idDestinatario = 13

In questo modo ho tutte le richieste inviate e ricevute da 13 (vabbè la query è una join ma il concetto della UNION è questo!)

Mi sembrava molto intuitivo, pensi che non vada bene?

[Nunkij]

Il campo nella SELECT è uguale, ovviamente. Non so perché non mi fa modificare il messaggio

[optime]

non ti basta

Select IdUtente
From tbAmici
Where idMittente = 13 OR idDestinatario = 13

???

[Nunkij]

Sinceramente non ci ho provato! Lo testerò

Grazie

[badaze]

non ti basta

Select IdUtente
From tbAmici
Where idMittente = 13 OR idDestinatario = 13

???

Penso di no. Se ha molti record la query non sarà optime () in questo caso. Ci vogliono due indici (uno sul mittente e l'altro sul destinatario) visto che ha deciso di non avere "doppioni".