concevoir pour des données répétitives

Question

Je suis en train de concevoir une base de données de produits et j'ai une question de conception.

Il existe plusieurs catégories de produits, par exemple les livres, les jeux vidéo, l'électronique domestique et les fournitures pour animaux de compagnie. Il y a certaines choses en commun, selon le fabricant, et le prix, alors que d'autres choses sont propres à chaque catégorie, par exemple la consommation d'énergie. Les produits individuels seront mis à jour périodiquement, le prix pourrait être volatil, tandis que le fabricant restera assez constant (je suppose qu'un fabricant pourrait être acheté par une autre société et le nom de marque absorbé dans la société d'achat). Les mises à jour peuvent avoir lieu toutes les heures. Les demandes pour chaque produit peuvent être faites fréquemment (dépend du nombre de clients, donc sans limite).

Je suis beaucoup plus préoccupé par la vitesse d'accès aux données pour les clients que je ne le suis pour la vitesse à laquelle je fais des mises à jour des données.

Ce qui est plus logique et pourquoi ?:

• une table pour toutes les catégories avec des colonnes peuvent être NULL (par exemple des fournitures pour animaux de compagnie aurait nulle pour la consommation d'énergie)
• une table pour chaque catégorie avec des colonnes répétées (par exemple le prix serait dans chaque tableau)
• une table pour les caractéristiques communes (prix, fabricant, etc ...), et une table pour les propriétés uniques

Answer 1

Je dirais une table pour les caractéristiques communes, et une autre avec des propriétés uniques.

Vous pourriez simuler quelque chose comme le motif décorateur, où les propriétés supplémentaires sont juste des étiquettes associées aux produits.

Vous voudrez probablement des regroupements d'étiquettes, pour faciliter l'ajout de nouveaux produits.

Avec la configuration ci-dessus, il est probablement plus facile de développer avec de nouvelles balises et d'ajouter/supprimer des balises lorsque les classifications changent.

---

Je pouvais voir les problèmes suivants avec les autres approches. Si tout était dans une table, vous deviez tout savoir à l'avance et changer constamment la table en tant que nouveau champ a été inventé et laisser beaucoup de champs comme NULL. Avec la table par catégorie, vous deviez créer de nombreuses requêtes différentes pour chaque type de produit et aller de l'avant, cela pourrait être difficile à maintenir.

Answer 2

Prenez du recul et sortez la tête de la base de données. Comment allez-vous résoudre cela dans votre application? Habituellement, vous utiliserez l'héritage. Les super classes définiront les propriétés communes, tandis que les sous-classes définiront les traits spéciaux.

Donc, votre question peut être réécrite comme: Comment puis-je implémenter l'héritage dans une base de données?

Tout d'abord, essayez d'éviter la duplication de données. Si vous faites une simple erreur dans vos transactions (ou dans votre code), les données peuvent devenir incohérentes et personne ne saura quel prix est le bon.

La grande table n'est probablement pas une bonne solution puisque vous voudrez éventuellement ajouter une nouvelle fonctionnalité. Cela conduit à un espace de plus en plus gaspillé dans votre base de données. De plus, vous devrez soit créer des requêtes par classe ou récupérer beaucoup de valeurs NULL de la base de données.

Cela conduit à un apporach multi-table. La classe de base commune correspond à la table centrale qui donne des ID aux instances. Toutes les sous-classes utilisent des tables spéciales plus petites qui ont une colonne ID qui est remplie à partir de la classe de base. Lorsque vous chargez des données, joignez toutes les tables pour une classe et chargez toutes les données en une seule fois (en utilisant l'ID dans toutes les tables).

C'est très efficace puisque la recherche de données va au-dessus de la clé primaire unique et la simple jointure ID = ID ne coûtera pas beaucoup.