Ajouter à une table un champ calculé

Version imprimable

01/12/2012, 20h58
Sinakhine

Ajouter à une table un champ calculé

Bonjour ,
Comment je peux Ajouter à une table une colonne calculée correspondant à la différence entre 2 colonnes .
je veux dés que j'insert un ligne dans ma table "voyage" le champs "KP" sera calculé automatiquement par la somme de 2 colonne de la même ligne de l'enregistrement
Merci pour votre aide
01/12/2012, 21h25
Exia_

Bonsoir,

dans une BDD aucune colonne ne doit contenir d'information calculé, si tu doit ressortir des données calculé tu doit le faire soit du coter de l'application soit directement avec une requête SQL qui se chargera de faire le calcul.
01/12/2012, 21h35
Sinakhine

comment je peux le faire directement dans ma base de donné sachant que je travail sous mysql .je ne sais pas comment créée une requête dés l'ajout il faut calculé la somme
Merci pour votre aide
01/12/2012, 22h02
Exia_

Tu devrait passer par un trigger qui agira avant l'insertion qui fera le calcul et ajoutera dans ta colonne ce calcul.
02/12/2012, 10h39
CinePhil
Non ! C'est seulement lorsque tu sélectionneras dans la table que tu procèderas au calcul !
Code:

1 2 SELECT col1, col2, col1 + col2 AS somme FROM la_table
03/12/2012, 12h54
SQLpro

ou faire une vue.

A +
05/12/2012, 14h21
maff92

Bonjour à tous,

Ca faisait longtemps que je voulais m'inscrire, c'est chose faite, car ce sujet m'intéresse beaucoup.

Donc pour répondre à Exia93, CinePhil et SQLpro, j'aimerais vous soumettre un exemple de cas d'utilisation, savoir quelle réponse vous y apporteriez.

Imaginons une table produit qui contiendrait, entre autres, un tarif HT et un taux de TVA (variant en fonction, par exemple, du type de produits, mais peu importe).

Si je veux lister les produits et afficher leur prix TTC, je devrai calculer le montant TTC à la récupération (en requêtage ou par une vue). Jusque là tout va bien.

Maintenant admettons que j'ai besoin de sélectionner des produits dans une certaine fourchette de prix TTC.
Ok, je vais requêter sur ma colonne calculée avec un truc du genre where ht+(ht*tva) >= xxx and ht+(ht*tva) <= yyy

Mais, si cette table contient plusieurs millions d'enregistrements, et que ces requêtes de sélection de fourchettes sont exécutées des milliers de fois par jour, nous sommes d'accord (je pense ?) que d'un point de vue performance, on risque d'être dans les choux.

Voilà, pour ma part, j'ai fait le choix de calculer le montant ttc au niveau applicatif, et le stocker dans une colonne que j'ai indexée. Les puristes m'ont bondi dessus à base de "dénormalisation", "premature optimization is root of all evil", etc. mais n'ont pas été capables de me proposer de solution alternative convenable.
Edit : J'avais également pensé à passer par une computed column (Sybase), mais il fallait de toutes façon la linker côté applicatif, donc ça ne résolvait pas le "problème" de dénormalisation.

Je suis preneur d'autres solutions, en avez-vous ?

Merci
05/12/2012, 14h47
CinePhil

Je fais une incursion provisoire du côté du processus.
Je ne me vois pas aller sur un site de vente en ligne et commencer par entrer une fourchette de prix sans avoir au préalable sélectionné une catégorie de produits ou alors ce site ne propose qu'une seule catégorie de produits. Dans ce cas, il est fort probable que le taux de TVA sera le même pour toute la catégorie de produits.

Citation:

(variant en fonction, par exemple, du type de produits, mais peu importe).

Dans mon hypothèse, cela importe car alors on peut, après avoir sélectionné le type de produits, récupérer le taux de TVA associé et on peut alors faire une condition WHERE plus efficace qui utilisera l'index sur le prix hors taxes :

Code:

WHERE ht BETWEEN :fourchette_basse / (1 + (:tva / 100)) AND :fourchette_haute / (1 + (:tva / 100))
05/12/2012, 15h02
SQLpro

Citation:

Envoyé par maff92

...

Voilà, pour ma part, j'ai fait le choix de calculer le montant ttc au niveau applicatif, et le stocker dans une colonne que j'ai indexée. Les puristes m'ont bondi dessus à base de "dénormalisation", "premature optimization is root of all evil", etc. mais n'ont pas été capables de me proposer de solution alternative convenable.

Ca c'est effectivement juste une imbécilité.
1) effectivement dénormalisation... mais justifiable pour les performances....
2) bien pire : quelle est la précision de vos calculs ? Le langage utilisé est-il conforme à la norme sur les arrondis et limites des calculs ? Faites vous toujours appel à la même formule ? Passerez vous toujours par la même et unique application ? Qui des performances des aller-retour de lignes pour le calcul de milliers de totaux ???

Citation:

Edit : J'avais également pensé à passer par une computed column (Sybase), mais il fallait de toutes façon la linker côté applicatif, donc ça ne résolvait pas le "problème" de dénormalisation.

Merci

C'est au minimum ce qu'il faut faire, voir mieux utiliser des vues indexées (MS SQL Server) ou matérialisées (Oracle).

Déjà MySQL comme PHP ne sont pas conforme aux normes de calculs (IEEE 754) et par conséquent leurs résultats de calculs peuvent être aléatoires...

http://www.ahristov.com/tutorial/Blo...EE%2Bhell.html

A +
05/12/2012, 15h51
CinePhil
Article intéressant. Sa conclusion :

Citation:

DO NOT USE FLOATS OR DOUBLES WITH DECIMAL FIELDS

Use either BigDecimal or BigInteger

Cela veut-il dire que lorsque je veux insérer une valeur dans une colonne de type DECIMAL il est préférable de fournir un entier et faire l'opération de division dans la requête ?
Par exemple, pour un prix avec 2 décimales pour les centimes, exécuter plutôt cette requête ?
Code:

1 2 3 UPDATE te_produit_prd SET prd_prix_ht = 12345 / 100 WHERE prd_id = 12
La division par 100 dans ce cas est-elle toujours juste ?

Citation:

Envoyé par CinePhil

Je fais une incursion provisoire du côté du processus.
Je ne me vois pas aller sur un site de vente en ligne et commencer par entrer une fourchette de prix sans avoir au préalable sélectionné une catégorie de produits ou alors ce site ne propose qu'une seule catégorie de produits. Dans ce cas, il est fort probable que le taux de TVA sera le même pour toute la catégorie de produits.

Dans mon hypothèse, cela importe car alors on peut, après avoir sélectionné le type de produits, récupérer le taux de TVA associé et on peut alors faire une condition WHERE plus efficace qui utilisera l'index sur le prix hors taxes :

Code:

WHERE ht BETWEEN :fourchette_basse / (1 + (:tva / 100)) AND :fourchette_haute / (1 + (:tva / 100))

Pour ton souci de TVA associé à une catégorie de produit, comme il n'y a pas 50000 taux de TVA, au lieu de calculer un prix hors taxes on peut surement calculer tous les prix hors taxes possibles :
Code:

1 2 3 4 5 6 WHERE (tva=9.6 AND ht BETWEEN $HTLimiteInfTVA96 AND $HTLimiteSupTVA96) OR (tva=18.6 AND ht BETWEEN $HTLimiteInfTVA186 AND $HTLimiteSupTVA186) OR (tva=19.6 AND ht BETWEEN $HTLimiteInfTVA196 AND $HTLimiteSupTVA196)