requête mysql table de relation normale vs table de realtionship concaténée

Question

J'ai une question sur les relations entre deux tables.

Disons que nous avons un utilisateur de table, et des liens.

users 
+++++++++ 
id name 
1 name1 
2 name2 
3 name3 
+++++++++ 

---

links 
+++++++++ 
id link 
1 link1 
2 link1 
3 link1 
+++++++++ 

Maintenant, la façon normale de relier ces deux est avec une table de name_links. Par exemple:

name_links 
++++++++++++ 
uid lid 
1 1 
1 3 
2 3 
2 1 
2 2 
3 2 
++++++++++++ 

Maintenant, je me demandais si elle est une bonne idée de faire une table que je peux penser comme ce

name_links 
++++++++++++ 
uid lid 
1 1,3 
2 1,2,3 
3 2 
++++++++++++ 

Avantages et inconvénients de sont:

pros1:

Vous chercherez toujours sur les index, les requêtes plus rapides exemple sélectionnez où uid = 1 puis sélectionnez les liens 1,3. Les deux sont des index donc ce sera une charge rapide.

Si vous avez 1000 utilisateurs, et ils ont chacun 20 liens, cela signifie que vous devez aller à travers 20.000 enregistrements pour obtenir tous les liens (je ne pense pas, sûr de cela). En utilisant cette méthode, vous ne prenez qu'un index et vous avez terminé.

CONS1:

Vous devez mettre à jour la table de name_links plus souvent, lire, modifier et écrire par exemple l'utilisateur 2 supprime lien2 la méthode sera:
+ obtenir la chaîne de l'utilisateur 1
+ supprimer le numéro de la chaîne
+ insérer la nouvelle chaîne

Tout ici est fait sur un indice, je suppose qu'il sera rapide.

CONS2:

Un autre con est lorsque vous supprimez lien 2, vous devez faire une dépression toutes les chaînes, mais permet de dire que ce n'est pas autant d'un problème, car cela ne se produira pas souvent .

C'est ce que je peux trouver jusqu'à présent, et je suis au point de mon projet où je dois décider avec lequel aller.

Je voudrais avoir quelques conseils sur la méthode à choisir. Est-ce que j'ai mes avantages et mes inconvénients? Y a-t-il des choses que je ne prends pas en considération. Toute aide sur ce sujet sera grandement appréciée.

Merci les gars!

Answer 1

solution dénormalisées a ces inconvénients:

• Vous ne pouvez pas joindre efficacement les noms et les liens (FIND_IN_SET n'est pas sargable)

• Vous ne pouvez pas appliquer l'intégrité référentielle à l'aide FOREIGN KEYs (en InnoDB)

• La suppression et l'ajout d'une relation nom-lien est plus complexe

Si vous ne recherchez jamais de noms avec un lien et que les liens sont peu nombreux, vous pouvez éventuellement vous débarrasser d'une jointure supplémentaire.

Vous devriez vous assurer que l'avantage de la performance est réel, vous en avez vraiment besoin et vous êtes conscient des complications liées au maintien d'une table dénormalisée.

Si les links sont corrigés, vous pouvez utiliser un type de données natif SET à la place.

Answer 2

Vous ne devez absolument PAS concaténer des enregistrements sauf si vous devez absolument le faire. Envisager les capacités futures, disons que vous voulez compter combien d'utilisateurs ont le lien 3, c'est une douleur avec votre deuxième méthode.

Donc, je suppose par votre exemple que ce sera une jointure plusieurs-à-plusieurs, ce qui signifie qu'un lien peut être connecté à de nombreux utilisateurs et que de nombreux utilisateurs peuvent être connectés avec un lien. Donc, vous avez potentiellement des attributs qui ont à voir avec un utilisateur se connectant à un lien, comme time_linked Cela pourrait aller sur votre table name_links.

Answer 3

Je ne suis en aucun cas un expert en base de données, mais votre deuxième option me semble être une très mauvaise idée. Même en supposant que vous n'aurez jamais besoin de faire, par exemple, une recherche par lien dans la table name_link, faire quoi que ce soit avec les liens sera beaucoup de travail supplémentaire (inutile, IMO).