J'ai une boutique en ligne où les utilisateurs peuvent avoir de petits magasins avec leurs propres produits. Chacun de ces produits peut avoir des questions qui lui sont associées et le propriétaire de la boutique a la capacité de répondre à ces questions. Cette information est stockée dans 3 tables une "question" (questionné, productide, ...), un "produit" (productide, shopid, ...) table et un "shop" (shopid, propriétaire, ...) table.
est-il préférable d'avoir un shopid dans la table "Questions" (pour permettre à un propriétaire de la boutique de voir toutes ses questions) ou de rejoindre ces trois tables pour faire correspondre une certaine boutique?
5 Réponses :
Généralement, il vaut mieux éviter les informations redondantes. Cela semble que cela devrait être assez bon marché de faire des indices appropriés et je ne dénormaliserais pas de cette manière à moins que je ne voyais dans les plans de requête que la jointure causait des problèmes (peut-être à cause du nombre d'enregistrements dans les tableaux) < / p>
Vous auriez également besoin d'envisager le ratio de lectures à écrire. La dénormalisation aidera les lectures mais ajouter des frais généraux à écrire.
La jointure sera assez bon marché uniquement pour les petites bases de données. Si vous envisagez de cardinalité pour un index sur Shopid dans la table des produits, la durée requise pour que la jointure soit importante.
@narcisradu - Oui, j'ai dû recourir à cela avant, mais le point que je faisait, c'est que cela ne devrait être fait que lorsque les plans d'exécution montrent une affaire pour cela.
Vous devriez avoir un grand nombre de relations entre les questions et les produits:
questions_ref (question_id, question_code, question)
produit_Questions (pQuestion_id, question_id_fk, produit_fk)
S'il est possible que le produit soit dans plusieurs magasins (que je suis certain, vous devez également avoir un grand nombre de relations entre les magasins et les produits.
shop_products (Sproduct_id, produit_id_fk, shop_id_fk, sproduct_price, autre_shop_specific_param)
Je ne pense pas que beaucoup de relations de nombreuses relations soient nécessaires ici. De plus, les tables sont une à plusieurs, afin que cela puisse faire l'objet d'une dénormalisation.
Juste une note; Si vous êtes confus, la «réponse de la question» serait une colonne dans la table Product_Quaistions
@narcisradu M2M est clairement nécessaire dans ce cas; Vous pouvez avoir de nombreux produits - un produit peut être dans de nombreux magasins: une question est sur de nombreux produits - un produit peut avoir de nombreuses questions.
@Drl Comme je l'ai dit dans un commentaire précédent, si les propriétaires de magasins sont différents, nous ne parlons pas du même produit. S'il vous plaît, pensez en dehors de la boîte, pas seulement d'une perspective de normalisation de la base de données.
@narcisradu J'ai répondu à votre commentaire précédent
@DSL - Cette conception serait meilleure pour un réseau de revendeurs, car vous avez des produits séparés des magasins et vous pouvez modifier un produit pour tous les magasins, mais dans l'affaire OP, les produits (et les questions) ne sont pas liés entre les magasins ( même si c'est le même produit). Chaque magasin voudra avoir sa propre description, un prix ou une propre description et principalement des réponses pour le produit et ne voudrez pas que cela soit modifié par un autre magasin, il n'y a donc pas besoin de tels produits «globaux», donc je pense qu'il est préférable de garder le Concevoir simple comme le design de l'OP.
Narcisradu a raison. Dans ce cas particulier, ni des produits ni des questions ne devraient avoir des relations m: m parce que même si tout est sur la même page, les magasins virtuellement sont complètement séparés.
Je pense que votre conception va bien. Je ne vais pas ajouter Shopid aux questions de la table. Vous devez utiliser une jointure, si nécessaire.
BTW: vous devriez utiliser une relation M: N entre produits et magasins et supprimer Shopid pour les produits. Vous pouvez donc avoir le même produit dans les différents magasins et aussi les mêmes questions pour un produit.
Cordialement, Lars
Il devrait certainement éviter d'utiliser une relation nombreuses à plusieurs entre produits et magasins si les commerçants sont différents. Imaginez qu'il y a le même produit, mais le prix diffère ou tout autre attribut diffère.
@narcisradu de sorte que vous auriez une table de produits pour chaque magasin? Son très simple à ajouter des paramètres spécifiques à la boutique à la table Shop_Products () dans mon exemple Shop_Products (..., Sproduct_price, Sproduct_stock)
@DRL: TELLEMENT OK OK, votre M2M entre les magasins et les produits est probablement indésirable. En tant que propriétaire de magasin, je voudrais que mes données soient complètement séparées des données d'un autre propriétaire d'une autre boutique, même si les deux ensembles de données vivent dans la même base de données. Et non, des tables de produits séparées par magasin sont des non-sens, mais oui, vous voulez une relation de 1 à m entre la boutique et le produit. Cela empêche les enchevêtrement des données entre les magasins et simplifiera grandement l'importation et l'exportation de données de produits pour un seul magasin. C'est important, car en tant que propriétaire de magasin, je veux mettre en place rapidement et pouvoir partir rapidement.
@Drl: Non, il a déjà shopid dans la table du produit. D'après ce que je comprends ici, il n'y a pas de produit "global". Chaque magasin a ses propres produits (ou peut-être que quelques magasins auront le même produit réel, mais ils seront considérés comme différents car non liés). Comme l'OP a dit que c'est un portail de boutique en ligne avec des boutiques en ligne différents et probablement non liées à l'intérieur, il n'y a pas de relation entre le produit, même si le produit réel est le même.
à partir d'un point de vue de conception, il n'est pas nécessaire de stocker des données redondantes. Dans votre cas, ce pourrait être. Essayez de faire des tests et si le temps de requête est amélioré en raison de cette redondance, vous devriez procéder à la dénormalisation.
Il est presque toujours préférable de rejoindre et d'éviter des informations redondantes. Vous ne devriez que Denormalize lorsque vous devez le faire afin de répondre à un objectif de performance - et vous pouvez ' t sais que si vous devez faire cela jusqu'à ce que vous essayiez avec normalisé Tables d'abord.
Notez que la dénormalisation aide à lire les performances au détriment de ralentissement des écritures et de rendre plus facilité à une erreur de codage de faire en sorte que les données soient désynchronisées (puisque vous stockez la même chose dans plus d'un endroit que vous avez maintenant Assurez-vous de tout mettre à jour).
Merci beaucoup tout le monde pour vos réponses utiles. J'étais presque convaincue qu'il serait préférable de stocker des informations redondantes, mais j'ai appris quelque chose de nouveau aujourd'hui. Certaines personnes ont souligné qu'il serait préférable d'avoir une relation M: M entre les produits et les magasins, mais cela n'a aucun sens (int cette affaire!) Parce que les propriétaires de magasins sont complètement différents (même les frais d'expédition, etc. sont complètement séparés). Par conséquent, il n'ya aucun moyen de partager plusieurs magasins (même s'il s'agissait du même produit physiquement pour ainsi dire).