Bonjour,
Dans le cadre de mon stage, je souhaite me servir d'une basse de données pour gérer les contacts (on précisera des informations sur notre relation avec le contact), je vois 2 options :
1) Créer 2 table :
Personne (ID_personne, nom, prénom, mail)
Contact (ID_personne, ID_contact, type_relation, niv_relation)     donc ID_contact correspond à une entrée de la table personne
 
2) ou Créer une table :
Personne (ID_personne, nom, prénom, mail, liste_contact, liste_type_relation, liste_niv_relation)  pour faire les lites j'utiliserais le type MEDIUMTEXT
 
La 2ème solution présente l'avantage de ne créer qu'une seule table avec n entré, mais nécessiterait de passer par un langage de programmation (python dans mon cas) pour gérer les listes
La 1ère solution devrait être plus rapide, mais pourra générer dans le pire des cas n^n (n puissance n) entrées dans la table contact    
 
Je suis en recherche il s'agit donc de maquette la solution 2) et logiquement meilleur, cependant dans l'optique d'une application à grande échelle cette solution restera-t-elle meilleur ?    
 
Merci  

1/ , sans hésiter  
 
dans la solution 2  , que se passe t il si mlle Blou se marie et change de nom ? tu dois changer toutes les entrés qui ont Mlle Blou en contact (remarque qu'un simple changement de numero de tel à le même effet )

je ne reponds pas au MP
 
je te confirme que je vote pour la solution a deux tables  :  personne + une table relation(idpersonnesource,idpersonnecible,type,niveau)
 
Dans ta solution 2 , tu stockes quoi dans tes mediumtext , des ID ? et comment tu associe un id a un type de relation ?

Je stockerai des listes d'ID_personne dans liste contact
Chaque liste aurait le même nombre d'entré, pour l'association il suffirait de prendre le Nème de liste_contact et de regarder le Nème de liste_type_relation
 
Donc dans le cas où les informations de madame Blou change je n'ai que l'entré de Blou à changer et aucune autre (pas besoin de toucher aux listes)
 
Le seul problème que je vois dans la solution 2 (1 table) et qu'en cas de suppression d'un élément d'une liste sans supprimer l'élément correspond dans les autres liste, cela modifierait toute les liens entre les relation suivant Nème-1 élément qui a était supprimé et qu'il serait impossible de rétablir (sauf sauvegarde ancienne) les bon liens
Mais il est très facile de prendre les disposition pour que cela n'arrive pas

comment tu fais pour facilement extraire les personnes qui ont Mlle bidule en contact ?  
 
tu fais une requete avec un truc du genre  WHERE liste LIKE ';$id;%'
 
c'est moche et couteux, bien plus qu'une jointure
 
 

Dans le cas de la solution à 2 table il n'y a même pas besoin de faire de jointure
 
Mais dans le cas que tu décris pas besoin de faire like non plus dans la solution à 1 table puis que tout les contact de Bob seront dans liste contact, j'aurais juste à faire
 
Where ID_personne IN liste_contact_Bob

Where ID_personne IN liste_contact_Bob ?
tu utilises quel SGBD ? parcequ'en mysql , sauf erreur de ma part, IN ne cherche pas  dans une chaine, mais dans une liste de resultats

Ha oui pardon, merci pour tes réponses je vais réfléchir aux requêtes possibles qui vont se présenter

Marrant, les gens ont l'air de considérer qu'une base de données relationnelles, c'est juste un endroit pour foutre des informations, et non pas pour les structurer et profiter de l'énorme travail fait au niveau du SGBDR pour gérer cette information structurée.  
 
C'est ahurissant de voir que l'on préfère faire un travail "manuel" sur une structure de données prévues explicitement pour que ce travail soit automatique et surtout plus efficace.
 
Edité : Faudra aussi m'expliquer d'où vient le n^n entrées dans ton premier message. A moins que les relations puissent être asymétriques et de plusieurs natures, ce sera au pire borné par m*n^2 où m est le nombre de types de relations différentes que tu envisages.