Question de conception d'une table

Question de conception d'une table - SQL/NoSQL - Programmation

Marsh Posté le 17-02-2007 à 11:50:19    

Bonjour tout le monde,
 
J'ai une table qui contient un champ A, un champ B et un champ C (de type integer ou float). Dans mon application j'ai souvent besoin de selectionner, de filtrer (where) et de trier (order by) par une valeur Z qui est (A * B / 2.5) + C
 
Je me pose une question existentielle : quelle est la meilleure façon de représenter ça ? Pour l'instant, j'ai imaginé 3 possibilités :
 
1) Selectionner Z à chaque requete, par exemple :

SELECT A, B, C, (A * B / 2.5) + C as Z [...] ORDER BY Z


 
2) J'ajoute un champ Z à ma table et dans mon application, à chaque fois que je modifie A, B, ou C, je met également Z à jour.
 
3) Je crée une vue de ma table qui contient Z.
 
Que conseillez-vous, et pourquoi ?
 
Merci pour votre aide !


---------------
When it's from Finland it's good.  - Mon blog
Reply

Marsh Posté le 17-02-2007 à 11:50:19   

Reply

Marsh Posté le 17-02-2007 à 13:32:04    

Ca dépend du SGBD en fait.
 
Certains permettent de créer des indexes basés sur le résultat d'une fonction (Oracle 8i et plus, par exemple: "function based index" ).
 
Mais ça n'est intéressant que si le volume de données est important, et si effectivement beaucoup des requêtes vont se servir de cet index ;)
Et tu perds un peu de perfs lors des insertions / mises à jour de la table.

Reply

Marsh Posté le 17-02-2007 à 14:18:16    

J'utilise mysql 5...

Reply

Marsh Posté le 17-02-2007 à 15:57:32    

Apparemment y a ni vue matérialisée, ni index basé sur une fonction avec mySql 5 ...
 
A toi de faire des tests donc.
Crée la table sous mySql, insère le volume de données qui te semble adéquat, crée ou non la colonne supplémentaire (indexée), et lance tes requêtes pour mesurer le gain ;)

Reply

Marsh Posté le 19-02-2007 à 14:54:43    

Pour reprendre ce que dit beegee, on a aussi les colonnes calculées, qu'on trouve sous SQL Server par exemple, et qui sont indexables (soit en utilisant l'index des champs d'origine, soit en stockant physiquement le résultat et en l'indexant). Mais bon, ça n'existe pas plus sous MySQL que le reste.
 
Tu as donc la solution de la vue. Niveau perfs, ce sera meilleurs que ta requêtes, mais il ne faut pas t'attendre à un super gain. Par contre c'est l'avantage de ne pas polluer ta table avec des données calculées, tout en conservant un moyen de retrouver ces valeurs simplement.
 
Reste la solution de créer ton propre système de colonne calculée, à savoir créer un champ Z, et créer deux trigger, un sur insert et un sur update, qui viendront le remplir (c'est l'assurance de ne pas avoir des données incohérentes dans ta table si un jour tu oublies de mettre à jour Z).
 
Normalement, tout ce dont tu as besoin pour faire ça sont dans MySQL 5


Message édité par MagicBuzz le 19-02-2007 à 14:55:43
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed