Question sur la conception de la base de données concernant les informations dupliquées

Question

J'ai une base de données qui contient un historique des ventes de produits. Par exemple, la table suivante

CREATE TABLE SalesHistoryTable (
OrderID, // Order Number Unique to all orders
ProductID, // Product ID can be used as a Key to look up product info in another table
Price, // Price of the product per unit at the time of the order
Quantity, // quantity of the product for the order
Total, // total cost of the order for the product. (Price * Quantity)
Date, // Date of the order
StoreID, // The store that created the Order
PRIMARY KEY(OrderID)); 

Le tableau comportera à terme des millions de transactions. À partir de là, des profils peuvent être créés pour les produits dans différentes régions géographiques (sur la base du numéro d'identification du magasin). La création de ces profils peut prendre beaucoup de temps en tant que requête de base de données. En voici un exemple.

SELECT ProductID, StoreID,
 SUM(Total) AS Total,
SUM(Quantity) QTY,
SUM(Total)/SUM(Quantity) AS AvgPrice
FROM SalesHistoryTable
GROUP BY ProductID, StoreID;

La requête ci-dessus peut être utilisée pour obtenir des informations sur les produits d'un magasin particulier. Il serait alors possible de déterminer quel magasin a vendu le plus grand nombre de produits, a gagné le plus d'argent et, en moyenne, vend le plus ou le moins cher. Il serait très coûteux de l'utiliser comme une requête normale exécutée à tout moment. Quelles sont les décisions de conception à prendre pour que ces types de requêtes s'exécutent plus rapidement, en supposant que la taille du stockage ne soit pas un problème. Par exemple, je pourrais créer une autre table avec des informations dupliquées. ID du magasin (clé), ID du produit, coût total, quantité, prix moyen. Et fournir un déclencheur de sorte que lorsqu'une nouvelle commande est reçue, l'entrée pour ce magasin est mise à jour dans une nouvelle table. Le coût de la mise à jour est pratiquement nul.

Quels sont les éléments à prendre en compte dans le scénario ci-dessus ?

Answer 1

Il s'agit normalement d'une tâche pour laquelle on utilise un entrepôt de données, mais à part cela, l'utilisation d'un déclencheur pour mettre à jour une deuxième table est une option tout à fait viable.

Vous pouvez également disposer d'une deuxième table qui est alimentée périodiquement par un travail par lots (une option plus proche de l'entrepôt de données). Vous pouvez également utiliser une vue matérialisée si votre base de données le permet.

Answer 2

J'y réfléchirais :

• une solution d'entrepôt de données/OLAP
• (comme vous l'avez dit) exécuter vos requêtes d'exploration de données sur une table/un ensemble de données précalculé(e) séparé(e)
• les vues indexées/matérialisées, ce qui est presque identique au point précédent

Quelques questions se posent cependant :

• attendez-vous des données en temps réel ?
• Quel est votre volume d'écriture ?
• Quel moteur DB ?

Answer 3

Vous pouvez envisager d'utiliser vues matérialisées qui ne sera interrogé que périodiquement.

Answer 4

"Le coût de la mise à jour est pratiquement nul.

Sauf que toutes les mises à jour doivent désormais être sérialisées. Car quoi qu'il en soit, l'ancienne loi de la physique reste qu'il ne peut y avoir deux choses au même endroit au même moment.