en termes de performance et d'évolutivité que l'on pourrait constituer une meilleure méthode pour faire un à de nombreux mappages dans MySQL.
Utilisation d'une colonne séparée mais coller sur 2 tables:
(personne): id, nom
(téléphone): id, numéro, type, personne_id
Utilisation d'une table séparée:
(personne): id, nom
(téléphone): id, numéro, type
(personne_phone): id, personne_id, téléphone_id
3 Réponses :
Il n'y a qu'une seule réponse correcte à cela, et c'est le premier.
La seconde de vos idées est la façon dont vous modélisez de nombreuses relations, pas à plusieurs.
Le second implique différentes personnes peuvent partager le même numéro de téléphone, ce qui est BS
C'est "BS"? Hein, ma femme et moi avons partagé le même téléphone depuis des années.
C'est juste un exemple, les gars. Sa question réelle est "lors de la cartographie de nombreuses relations". Rester calme :)
Lorsque mon bureau a ouvert la première fois, il était courant que 4-6 développeurs attribuaient 1 téléphone partagé. Qu'est-ce que les codeurs ont besoin de parler aux gens? ;)
en termes de performance, il est toujours moins cher d'éviter les jointures, qui ajoutent une multiplicité à la quantité de lignes à interroger.
tant que un seul téléphone ne sera utilisé que par un employé (un vrai à plusieurs), la première option est la meilleure.
Bien sûr, il existe des compromis dans d'autres domaines avec minimiser les jointures. Sinon, tout le monde utiliserait simplement des bases de données à table (ce qui n'est pas aussi ridicule que cela sonne ... ils avaient une fois un sizable suivant). Mais vous avez raison que l'ajout rejoindre s pour les ajouter ne va pas faire votre performance des faveurs.
premier est meilleur.
P.s. Peut-être que vous n'avez même pas besoin id pour téléphone, (numéro, type, personne_id) suffit.
Dommage que je puisse éteindre une seule fois, besoin d'un uppote séparé pour P.S. :)
Dans quelles circonstances imaginez-vous faire deux jointures pour atteindre les données dont vous avez besoin sera plus rapide que de faire une seule jointure?
J'ai mentionné la performance et la scabondie. Je me demandais si vous avez une table séparée le rendrait plus évolutif.
@Dan: Peut-être enfreindre le schéma sur plusieurs serveurs de base de données? [Avertissements Niveaux de caféine obtenus il y a longtemps, cela pourrait donc ne pas être le meilleur argument]
@Shoaibi Comment cela serait-il lié à la création de tables superflues? Je ne vois pas la connexion.
Ok, dans quelles circonstances imaginez-vous que des jointures seront mieux que de réaliser une seule jointure?
BTW, vous n'avez pas besoin d'un
ID dans l'une de ces tables, sauf peut-êtrepersonne . Chaque table n'a pas besoin d'un identifiant artificiel.Je pensais le long des lignes comme s'il y a un milliard d'enregistrements, nous pouvons potentiellement mettre toutes les tables sur des serveurs distincts. La défaillance n'est peut-être pas une question la plus sage que j'ai posée.
@Dan: YA, aurait pu aller avec une clé composite comme (nombre, type, personne_id). Exemple mutile.
Plus généralement, vous échouez sur plusieurs bases de données via un partitionnement horizontal (mettre tous les utilisateurs dont les identifiants sont même sur le serveur 1, impair sur le serveur 2), pas par la table. Vous ne pouvez pas rejoindre une table sur un autre serveur pour une chose.