Architecture SQL, faire des favoris
Résolu
Yuh12
Messages postés
184
Date d'inscription
Statut
Membre
Dernière intervention
-
Yuh12 Messages postés 184 Date d'inscription Statut Membre Dernière intervention -
Yuh12 Messages postés 184 Date d'inscription Statut Membre Dernière intervention -
Bonjour gentes gens,
Petit problème d'architecture SQL, en terme de ressources :)
Je possède
- une table Utilisateur.
- une table Media.
J'aimerais qu'un Utilisateur puisse ajouter un Media en favoris.
La solution serait donc de faire une table Favoris avec
- un id
- une clé étrangère pour l'id Utilisateur
- une clé étrangère pour l'id Média
Ainsi j'aurais un tableau du style
id_favoris user_id media_id
1 2 17
2 2 32
3 2 12
4 17 3
5 17 13
6 17 12
Ainsi l'utilisateur n°2 a ajouté en favoris les médias 17,32 et 12.
Et l'utilisateur n°17 a ajouté les médias 3,13 et 12.
Une autre solution serait de faire une colonne supplémentaire "Favoris" dans la table Utilisateur.
Ainsi nous aurions dans la table Utilisateur :
id_utilisateur nom favoris
1 Machin 17,32,12,248,56
2 Bidule 2,16
3 Chouette 46,29,323,102
Ce qui me parait être un autre moyen correct. Maintenant ma question, imaginons que l'on ait 1000 utilisateurs et 8000 Médias, quelle serait la solution la plus efficace en terme de ressources?
Dans le premier cas ma table risque de faire un nombre monstrueux de lignes...
Dans le deuxième cas la colonne "favoris" de ma table Utilisateur va s'incrémenter à l'infini, est ce que ma BDD supporterais une ligne avec 100 favoris?
Y aurait-il une autre solution à laquelle je n'aurais pas songé?
Merci d'avance et bonne journée à tous !
Petit problème d'architecture SQL, en terme de ressources :)
Je possède
- une table Utilisateur.
- une table Media.
J'aimerais qu'un Utilisateur puisse ajouter un Media en favoris.
La solution serait donc de faire une table Favoris avec
- un id
- une clé étrangère pour l'id Utilisateur
- une clé étrangère pour l'id Média
Ainsi j'aurais un tableau du style
id_favoris user_id media_id
1 2 17
2 2 32
3 2 12
4 17 3
5 17 13
6 17 12
Ainsi l'utilisateur n°2 a ajouté en favoris les médias 17,32 et 12.
Et l'utilisateur n°17 a ajouté les médias 3,13 et 12.
Une autre solution serait de faire une colonne supplémentaire "Favoris" dans la table Utilisateur.
Ainsi nous aurions dans la table Utilisateur :
id_utilisateur nom favoris
1 Machin 17,32,12,248,56
2 Bidule 2,16
3 Chouette 46,29,323,102
Ce qui me parait être un autre moyen correct. Maintenant ma question, imaginons que l'on ait 1000 utilisateurs et 8000 Médias, quelle serait la solution la plus efficace en terme de ressources?
Dans le premier cas ma table risque de faire un nombre monstrueux de lignes...
Dans le deuxième cas la colonne "favoris" de ma table Utilisateur va s'incrémenter à l'infini, est ce que ma BDD supporterais une ligne avec 100 favoris?
Y aurait-il une autre solution à laquelle je n'aurais pas songé?
Merci d'avance et bonne journée à tous !
A voir également:
- Architecture SQL, faire des favoris
- Logiciel architecture gratuit - Télécharger - Architecture & Déco
- Exporter favoris chrome - Guide
- Exporter favoris firefox - Guide
- Architecture 3d gratuit - Télécharger - Architecture & Déco
- Logiciel de plan de maison : les meilleurs outils gratuits - Guide
2 réponses
Bonjour,
L'autre solution est de mettre dans la table utilisateurs un champ supplémentaire favoris de type longtext. Ainsi vous n'avez pas besoin de créer et gérer votre table supplémentaire.
Dans ce champ favoris, vous mettez la sérialisation des favoris, exemple:
et plus loin dans le SQL:
xxx étant l'id de l'utilisateur
Pour le rajout ou suppression d'un favori:
$favoris = unserialize($champFavori);
pour la suppression d'un favori, passer par une boucle foreach:
et vous réenregistrez avec SQL
Avec cette solution, pas besoin de table supplémentaire, ni de jointure et tout le bastringue
A+
public function meilleurProgrammeurDuMonde() { return "MOI"; } // humour
L'autre solution est de mettre dans la table utilisateurs un champ supplémentaire favoris de type longtext. Ainsi vous n'avez pas besoin de créer et gérer votre table supplémentaire.
Dans ce champ favoris, vous mettez la sérialisation des favoris, exemple:
$favoris = array(17,27,32);
et plus loin dans le SQL:
$sql = "UPDATE utilisateurs SET favoris='".serialize($favoris)."'" WHERE id=xxx"
xxx étant l'id de l'utilisateur
Pour le rajout ou suppression d'un favori:
$favoris = unserialize($champFavori);
$favoris[] = 44; // rajoute le favori 44
pour la suppression d'un favori, passer par une boucle foreach:
$aSupprimer = 27; // valeur à supprimer
foreach ($favoris AS $key => $val)
if ($val == $aSupprimer) {
unset($favoris[$key])
}
}
et vous réenregistrez avec SQL
Avec cette solution, pas besoin de table supplémentaire, ni de jointure et tout le bastringue
A+
public function meilleurProgrammeurDuMonde() { return "MOI"; } // humour
Donc à partir de ma deuxième proposition, un longtext suffirait pour stocker les favoris? Même si un utilisateur met plus de 100 médias en favoris, en terme de ressources il n'y aura pas de problème?
Merci beaucoup pour ces conseils en tout cas !!!
Merci beaucoup pour ces conseils en tout cas !!!
la sérialisation d'un ARRAY ne contenant que des valeurs numériques prendra en fait très peu de place. Un longtext prend la place en BDD en fonction de son contenu. Un longtext contenant un array sérialisé de 100 valeurs fera moins de 1Ko, une paille en somme. En tout cas beaucoup moins que votre première solution. De plus, vous n'aurez pas besoin de jointures entre tables vu que pour chaque utilisateur on a directement ses favoris associés à sa fiche.