[SGBD]Normalisation Hosting images

Normalisation Hosting images [SGBD] - SQL/NoSQL - Programmation

Marsh Posté le 26-09-2007 à 19:11:08    

Bonjours, je suis en 2éme année de DUT Info, et on a un projet de Base de donnée, on doit faire la normalisation dans une matière, puis on réalise ce projet en php (a partir d'octobre).
 
Donc on a choisis de réaliser un système d'hébergement d’images, comme imageshack.us, mais comme c'était un peu léger, on a ajouté d'autres fonctionnalités:
Hébergement simple: l'image est accessible par un lien, l'utilisateur peut l'utiliser par exemple sur des forums...
Herbagement prive: seul les amis de l'utilisateur peuvent voir ses images
Hébergement publique: l'image est accessible sur le site de notre projet, elle est rangée dans sa catégorie...
 
Les images peuvent être notées par les internautes inscrits
 
Voici notre dictionnaire des données:
N°Image
N°Utilisateur
Pseudo
Mot de passe
email
Nom image
Admin (sert a déterminer si l'utilisateur est un administrateur ou non)
Note Image
effectif note (pour mettre a jour la note lors d'un nouveau vote)
Droit (public/prive/simple)
Catégorie
votes (stock les n° des utilisateurs ayant deja voté pour cette image)
 
Et il se trouve qu'on a un gros problème pour gérer la fonction amis, comment mémoriser les liens d’amitié ?
 
On a rejeté l’idée de créer une table du style :
 
Utilisateur1 Utilisateur2
Utilisateur1 Utilisateur3
Utilisateur1 Utilisateur4
Utilisateur2 Utilisateur1
Utilisateur2 Utilisateur3
Utilisateur3 Utilisateur1
Utilisateur3 Utilisateur2
Utilisateur4 Utilisateur1
 
Parce qu’on stock plusieurs fois le même lien d’amitié (Utilisateur1 Utilisateur4
= Utilisateur4 Utilisateur1)
 
Alors bien sur, on peut ne pas stocker les doublons :
Utilisateur1 Utilisateur2
Utilisateur1 Utilisateur3
Utilisateur1 Utilisateur4
Utilisateur2 Utilisateur3
Utilisateur3 Utilisateur1
 
Mais la, on a un problème : on ne peut plus se « fixer » sur une colonne, et regarder ce qu’il y a dans l’autre colonne, ça se lis dans les deux sens !
 
Donc en gros on patauge complètement alors si une âme charitable pouvais nous aider…
Et merci de m’avoir lu jusqu’ici.

Reply

Marsh Posté le 26-09-2007 à 19:11:08   

Reply

Marsh Posté le 26-09-2007 à 19:28:31    

pourtant la première solution me semble bonne...
 
c'est pas parceque tu me mets dans ta liste d'amis que tu fais partie de ma liste d'amis
 
en effet, sinon c'est un trou de sécurité... tu mets dans tes amis un gars, et sans même qu'il te connaisse, tu vois ses images... à moins que vous vous lanciez dans un workflow de validation de l'amitiée (principe de MSN par exemple), mais c'est bien du bordel pour pas grand chose.
 
dans ce cas, une simple contrainte user_id1 < user_id2 permettra d'éviter les doublons.
 
ensuite, pour trouver la liste des amis, se sera bancale mais fonctionnel :
 

Code :
  1. SELECT case user_id1 when $id then user_id2 else user_id1 end AS ami
  2. FROM amitie
  3. WHERE user_id1 = $id OR user_id2 = $id


 
=> On voit tout de suite un lourd problème de performances (entre le case et le fait que seul un des deux champs est accessible par index, ça fait beaucou)


Message édité par MagicBuzz le 26-09-2007 à 19:33:21
Reply

Marsh Posté le 26-09-2007 à 19:43:49    

En fait, on souhaite faire des liens bidirectoinneks pour l'amitié, avec une validation pour l'amitié (par mail), en utilisant 2 champs supplémentaires dans la table amitié: n°lien et état:
User1 veut devenir amis avec User2
Cela a pour effet de créer une entrée dans la table amitiée, avec état a 0. Tant que état est a 0, le lien d'amitié n'est pas fonctionnel.
User2 recoit par mail un lien, sur lequel il peut cliquer pour devenir amis avec User1, ce qui a pour effet de passer l'état a 1, et donc le lien devient fonctionnel.
 
Les liens non validés (état = 0) seront supprimé a interval régulier (maintenance).
 
Il faudrais donc une méthode plutot optimisé pour trouver qui est amis avec qui.

Reply

Marsh Posté le 27-09-2007 à 08:31:42    

Solution 2 avec trigger sur insert, qui écrit la réciproque de l'amitié à sa création alors. Je ne vois pas d'autre solution. Evidement, trigger sur delete pour supprimer les deux liens d'un coup, ainsi que sur update histoire de débloquer le status en même temps.
 
Mais on peut aller plus loin et faire sauter une limitation de ton système : lorsque je mets un pote dans ma liste d'amis, c'est normal que je doive attendre sa confirmation pour accéder à ses images. Mais il n'y a aucune raison pour qu'il ne puisse pas tout de suite accéder à mes images.
 
Pour cette raison, t'as même pas besoin de trigger ou autre.
 
u1 ajoute u2 à ses amis :
insert into amitie (pers, ami) values (u1,u2)
=> + envoi de mail "de validation" à u2. ce mail pointe vers une page qui fera
insert into amitie (pers, ami) values (u2,u1)
 
et ton problème est résolu. tu fais l'économie du status, des triggers, t'as un truc à double entrée, et fonctionellenement parlant, c'est plus souple.


Message édité par MagicBuzz le 27-09-2007 à 08:32:21
Reply

Marsh Posté le 27-09-2007 à 11:38:41    

C'est en gros le principe de "Copains d'avant" ;)

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed