Une grande table ou des tables séparées pour stocker les avis sur les types de pièces?

Question

J'ai besoin de faire une centaine de tables. J'ai des tables appelées PartStatsXXX et les tables à faire seront toutes appelées PartReviewXXX (elles se couplent entre elles dans une relation 1: n).

Est-il efficace de créer une grande table pour stocker tous les avis sur le produit (le produit et la pièce étant du même point de vue commercial)? Quelqu'un a mentionné faire une relation de PartStatsXXX à PartsReview (une grande table) avec la valeur de XXX comme partie de la clé primaire de PartStatsXXX. XXX est le nom du type de pièce (par exemple batterie, métier à tisser, etc.).

Donc ce sera varchar. Dois-je faire une clé composite? Le type de pièce ne change pas de nom (bien que certains noms de pièces puissent avoir plusieurs noms selon la culture), mais ce n'est pas vraiment un identifiant de candidat. Il a ensuite été mentionné que je pouvais obtenir plusieurs vues pour ce dont j'avais besoin en fonction de la valeur de XXX.

J'espère que cela a du sens. Quelle serait la meilleure approche?

Merci

Answer 1

multi-tables PartStatsXXX est une mauvaise idée: difficile de coder correctement ou avec un cadre, plus difficile à maintenir, cauchemar pour interroger ...

Utilisez deux tables: PartStats et PartsReview, avec touches et index appropriés pour la performance.

Answer 2

Il est plus efficace de créer des tables en fonction de ce que vous voulez stocker dans chacune d'entre elles. Vous n'avez pas besoin de 100 tables pour 100 produits. vous avez besoin d'une table pour tous les produits.

Donc, pour vos besoins Je voudrais créer 2 tables:

products 
======== 
id INT 
name VARCHAR 

product_reviews 
=============== 
id INT 
product_id INT (foreign key to products.id) 
rating INT (example column) 

Answer 3

À moins que vous stockez différents types de données pour les commentaires de chaque produit (chaque table a un ensemble de colonnes différentes), en utilisant une autre table par produit va créer un cauchemar inutile.

En règle générale, vous ne voulez jamais avoir plus d'une table avec le même ensemble de colonnes. Comme déjà suggéré, une table avec une colonne "product_id" est le chemin à parcourir.

Answer 4

Si vous voulez vous épargner de la douleur de manière rapide et sale, utilisez deux tables.

CREATE TABLE PartStats (
    ..., 
    PartType VARCHAR(255), 
    ... 
); 

CreateTable PartReview (
    ... 
    PartType VARCHAR(255), 
    ... 
); 

puis les rejoindre via

SELECT ... 
FROM PartStats ps JOIN PartReview pr 
    ON ps.PartType = pr.PartType; 

Cela vous sort d'avoir des centaines de tables, mais vous met en place pour un autre problème: les données redondantes (parttype) qui peuvent se désynchroniser . Une faute de frappe dans un PartType peut entraîner une révision orpheline. La solution ici, en supposant que vous pouvez avoir plus d'une entrée PartStats pour un PartType donné, consiste à ajouter une table troisième à la seule ancienne des noms PartType. Et de faire en sorte que PartStats et PartReview utilisent l'ID d'un PartType. Par exemple,

CREATE TABLE PartStats (
    ..., 
    PartType_ID INT REFERENCES PartType(ID), 
    ... 
); 

CREATE TABLE PartReviews (
    ... 
    PartType_ID INT REFERENCES PartType(ID), 
    ... 
); 

Cela permettra d'éviter votre faire un PartStats ou un PartReview pour une PartType inexistante.

Si les performances de la requête deviennent un problème, l'ajout d'index secondaires sur PartType_ID vous aidera.

Answer 5

Je peux vous recommander quelques livres pas mal sur la conception de base de données (il y a plusieurs mois j'ai décidé d'améliorer ma base de données des compétences de conception, donc j'ai regardé plusieurs livres différents et a choisi ces deux):

1) Pro SQL Server 2008 conception de bases de données relationnelles et mise en œuvre (c) Louis Davidson
2) conception de bases de données relationnelles expliquer clairement (c) Jan Harrington

Bonne chance!