Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 11 sur 11
  1. #1
    Invité régulier
    Femme Profil pro Sin Khane
    Inscrit en
    octobre 2012
    Messages
    16
    Détails du profil
    Informations personnelles :
    Nom : Femme Sin Khane
    Localisation : Belgique

    Informations forums :
    Inscription : octobre 2012
    Messages : 16
    Points : 7
    Points
    7

    Par défaut 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

  2. #2
    Membre Expert
    Homme Profil pro
    Étudiant
    Inscrit en
    avril 2012
    Messages
    764
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : avril 2012
    Messages : 764
    Points : 1 374
    Points
    1 374

    Par défaut

    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.

  3. #3
    Invité régulier
    Femme Profil pro Sin Khane
    Inscrit en
    octobre 2012
    Messages
    16
    Détails du profil
    Informations personnelles :
    Nom : Femme Sin Khane
    Localisation : Belgique

    Informations forums :
    Inscription : octobre 2012
    Messages : 16
    Points : 7
    Points
    7

    Par défaut

    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

  4. #4
    Membre Expert
    Homme Profil pro
    Étudiant
    Inscrit en
    avril 2012
    Messages
    764
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : avril 2012
    Messages : 764
    Points : 1 374
    Points
    1 374

    Par défaut

    Tu devrait passer par un trigger qui agira avant l'insertion qui fera le calcul et ajoutera dans ta colonne ce calcul.

  5. #5
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 820
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 820
    Points : 24 813
    Points
    24 813

    Par défaut

    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
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  6. #6
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 563
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 563
    Points : 30 071
    Points
    30 071

    Par défaut

    ou faire une vue.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  7. #7
    Invité de passage
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    décembre 2012
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : décembre 2012
    Messages : 1
    Points : 1
    Points
    1

    Par défaut

    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

  8. #8
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 820
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 820
    Points : 24 813
    Points
    24 813

    Par défaut

    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.
    (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))
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  9. #9
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 563
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 563
    Points : 30 071
    Points
    30 071

    Par défaut

    Citation Envoyé par maff92 Voir le message
    ...

    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 ???

    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  10. #10
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 820
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 820
    Points : 24 813
    Points
    24 813

    Par défaut

    Article intéressant. Sa conclusion :
    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 ?
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  11. #11
    Membre chevronné
    Homme Profil pro Frédéric
    Inscrit en
    juin 2011
    Messages
    442
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric
    Localisation : France

    Informations forums :
    Inscription : juin 2011
    Messages : 442
    Points : 612
    Points
    612

    Par défaut

    Citation Envoyé par CinePhil Voir le message
    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)

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •