Bases de données, E-commerce La gestion des catégories dynamiques dans les sites d’e-commerce
Articol_SQL image couverture

Bases de données, E-commerce

La gestion des catégories dynamiques dans les sites d’e-commerce

Comment accélérer les sites d’e-commerce grâce à la redondance des données ?

Avec le développement de l’ e-commerce et des nouveaux dispositifs d’accès à l’internet (tablettes, smartphone, …), la vitesse de chargement des pages est devenue critique pour les sites de vente en ligne. L’abandon des utilisateurs en cours de route est difficilement quantifiable. Pour les sites d’e-commerce quelques secondes de ralentissement dans le téléchargement se traduiront par un manque à gagner significatif car moins de consommateurs, moins de commandes et évidemment perte de chiffre d’affaire.

Pour les applications développées à partir de bases de données, le principal facteur est la vitesse à laquelle on transfère les données du serveur SQL, qu’il soit Oracle, SQL Server ou MySQL.

Les choses sont relativement simples lorsqu’une page de présentation de produit, n’exécute qu’une interrogation sur la table des produits selon l’ID, avec quelques liaisons. Elles deviennent plus complexes lorsqu’il s’agit des catégories créées dynamiquement.

Les catégories créées dynamiquement sont un produit cartésien entre les catégories et les produits. Une catégorie contient plusieurs produits, un produit appartient à plusieurs catégories.

Par exemple, ce cas :

– table de catégories – ID catégorie + informations spécifiques à la catégorie
– table de produits – ID produit + informations spécifiques au produit
– table des étiquettes – ID étiquette + informations afférentes
– table de liaison entre les produits et les étiquettes (relation multi à multi)
– table de liaison entre les catégories et les étiquettes (relation multi à multi)

Et voici les tableaux (version simplifiée) :

Etiquettes

fr01etiquettes

Catégories

fr02categories

Produits

fr03produits

Liaisons entre les tables :

Liaisons entre les tables

Dans le modèle le plus simple, pour obtenir la liste des produits d’une catégorie, nous avons besoin d’une interrogation sur cinq tables. Ensuite, pour un ordonnancement des produits dans une catégorie selon le prix, les plus vendus, les notes accordées par les consommateurs, les plus récents, etc., d’autres paramètres sont à prendre en compte.

Par exemple, l’ordonnancement selon « les plus vendus » se fait en fonction de chaque catégorie. Pour la catégorie « Cadeaux pour hommes personnalisables avec photo », nous allons tenir compte des ventes des 90 jours précédents. Pour la catégorie « Saint Valentin: Cadeaux pour femmes », nous allons tenir compte des ventes d’avant la Saint Valentin. Autrement, l’ordonnancement ne serait pas révélateur.

Il n’est pas difficile de deviner qu’à notre requête il faut ajouter des liaisons vers les tables de commandes. Si les catégories et les produits sont peu nombreux en quantité (quelques milliers de produits, quelques dizaines de catégories), les commandes et leurs détails ne vont pas atteindre l’ordre des centaines de milliers.

Une solution que j’ai appliquée avec succès a été la création d’une table pré-calculée qui contient une liaison directe entre les catégories et les produits, ainsi que d’autres informations utiles : ordonnancement selon le prix, ventes, notations, nouveautés. Conformément à la théorie des bases de données relationnelles, les informations de cette table sont redondantes (elles peuvent être obtenues des tables existantes).

Le diagramme devient :

Le diagramme devient

Ainsi, notre interrogation des 7-10 tables devient une interrogation simple, sur 2 tables, produits et catégories_produits :


select P.ID_Product, P.Description_Product
from Products P
inner join Categories_Products CP on P.ID_Product = CP.ID_Product
Where CP.ID_Category = 24011
order by CP.Sales_Rnk

En tant que vitesse d’exécution sur une base de données en production, l’avantage est évident:

fr04interrogation

Le seul inconvénient est que lorsqu’on ajoute / étiquette un produit, il n’apparaît pas sur les pages des catégories adéquates tant que la procédure stockée, qui fait la mise à jour des données dans la table catégories_produits, n’est pas exécutée. Il s’agit d’un inconvénient mineur pour les opérateurs qui travaillent sur le back office du site (nécessite un simple clic supplémentaire pour lancer la mise à jour de la base), par rapport au gain de vitesse d’affichage de la page du front office. La mise à jour de la table pré-calculée peut aussi se faire automatiquement, avec un job SQL lancé à une heure préétablie.

En conclusion, lorsque la vitesse de chargement des données est critique, nous pouvons dévier de la normalisation des bases de données relationnelles, afin d’obtenir le résultat souhaité.

Il existe surement d’autres méthodes pour diminuer le temps d’exécution des requêtes.  En fonction des particularités de l’application que nous souhaitons développer, il faut choisir la solution la plus efficace pour le client.  Il n’existe pas une recette universelle qui donne les mêmes résultats pour tout type d’application.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Facebook
Google+
http://blog.beleringenierie.com/2016/08/25/la-gestion-des-categories-dynamiques-dans-le-e-commerce/?rel=author">
Twitter