Conception de bases de données

1. Les problèmes de performance sont liés au tri qui s'effectue sur le prix d'une part ;

2. et aux jointures qui doivent être exécutées entre toutes les tables de la base pour pouvoir extraire la liste de toutes les figurines avec leurs caractéristiques.

Une première optimisation évidente concerne l'indexation du champ prix, elle permettra d'accélérer l'opération de tri, et ses effets indésirables (ralentissement de la mise à jour et augmentation du volume disque) seront négligeables.

1. Si l'on devait rester en relationnel on pourrait dénormaliser le modèle de façon à ne plus avoir à faire de jointure, ou à en faire moins selon le degré de dénormalisation.

2. Cette solution engendrerait de la redondance, qu'il faudrait contrôler par ailleurs, au niveau applicatif et/ou au niveau de la base de données, par des triggers par exemple.

3. Une alternative serait de créer une vue matérialisée qui pré-calculerait les jointures (et le tri par la même occasion).

4. L'inconvénient est que cette vue introduirait un décalage entre ce qui est présent dans la base et ce que l'on visualise sur le site. La calcul de la vue n'étant que de quelques secondes, on pourra envisager, sans surcharger le serveur, un nouveau calcul de la vue à chaque mise à jour des données liées, déclenchée par un trigger par exemple.

(Notons que les solutions de partitionnement ne seraient d'aucun intérêt étant donné que toutes les données, enregistrements et attributs, doivent être retournées ; à moins d'une partition sur le prix cela aura même un effet négatif étant donné qu'il faudra réaliser l'union avant le tri par prix).