Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Voici mon problème :
Dans une table postgres nommée adr j'ai créé plusieurs colonnes dont une appelée total (de type money)
doit être le résultat du produit de la colonne val (pour valeur de type money) par la colonne nb (pour nombre de type integer) . résumons : total = val x nb .
Aprés consultation de la documentation postgres je pensais avoir résolu mon problème avec la requête :
ALTER TABLE adr ALTER COLUMN tolal SET DATA TYPE money USING nb * val ;
Mais à l'exécution j'ai pour résultat :
ERREUR: la colonne « tolal » de la relation « adr » n'existe pas
État SQL :42703
Pour quelle raison postgresql va-t-il chercher une relation alors que je fais un ALTER sur une table ?
Si quelqu'un a une idée je le remercie par avance.
Hors ligne
Bonjour.
Dans postgresql, une table est un des types de relation.
Je pense qu'il y a une faute, vous avez écrit "tolal" et non "total".
Sinon, vous pouvez également utiliser une vue pour éviter de stocker un résultat calculable.
Julien.
https://rjuju.github.io/
Hors ligne
rjuju a raison, il y a plusieurs choses dans votre message :
1. erreur de frappe sur "total" 
2. notion de relation : une relation c'est une table (http://fr.wikipedia.org/wiki/Bases_de_d … tionnelles). PostgreSQL utilise le terme relation, qui est plus proche de l'algèbre relationnelle, alors que dans la vie "courante" on dit plutôt table.
3. on ne stocke généralement pas les résultats de calculs dans une base de données relationnelle. Le principe est justement de stocker uniquement les informations nécessaires pour pouvoir reconstituer à partir de celles-ci tous les résultats dont on peut avoir besoin. C'est lorsque vous ferez une requête que vous calculerez le total.
4. hier j'ai lu (ici : http://archives.postgresql.org/pgsql-jd … 00117.php) que le type money n'était pas une bonne idée (NUMERIC est moins dangereux et moins pénible à utiliser). Voir aussi ici : http://forums.postgresql.fr/viewtopic.php?id=1130 où la conclusion est la même.
5. l'ordre ALTER TABLE ne va calculer la valeur de total qu'au moment où vous le faites. Il ne positionne pas la valeur par défaut (je ne sais pas si c'était clair pour vous). Un ordre alter table c'est un ordre de modification de structure : pour diverses raisons, ce n'est pas ce qu'il faut utiliser pour mettre à jour la colonne total (sauf en one-shot pour faire une évolution de schéma...). Comme précise rjuju, si vous voulez simplifier le travail des développeurs, vous pouvez faire une vue.
Flo
Dernière modification par flo (22/12/2011 11:11:41)
Hors ligne
En fait, comme des fonctions du style pg_relation_size() donnent des informations sur les tables, mais aussi les index et autre, je pensais que le terme relation avait un sens plus large.
Julien.
https://rjuju.github.io/
Hors ligne
euh oui il me semble (faudrait demander à Marc la définition exacte, c'est lui l'expert de la théorie des bases de données... ) mais je pensais que ce n'était pas la peine d'embêter un débutant avec ces questions.
Hors ligne
Houla, j'ai lu des livres, ça fait pas de moi un expert…
Marc.
Hors ligne
Une relation c'est l'objet mathématique porteur de données à l'origine de l'algèbre relationnelle de Codd...
pourquoi le terme relation ? On a oublié que lorsqu’un journaliste fait un compte rendu d'un événement, il relate les faits, il fait une relation de l'événement. Ce de ce sens profond que le terme relationnel vient.
A la différence d'une table les relations ont les propriétés suivantes :
- Les attributs d'une relation doivent pouvoir stocker n'importe quelle type d'information atomique (numérique, littéraux, images, son, vidéo...)
- Tous les attributs d'une relation doivent être valués (pas de NULL)
- Toute relation doit avoir une clef (équivalent de la clef primaire d'une table).
Pour ce qui est des colonnes calculées, les solutions sont actuellement limitées sous PG : il n'existe ni colonne calculée persistantes (calcul stocké avec les données) ni index sur expression calculé, ni de vues indexées... contrairement à oracle ou SQL Server.
Seule solution, créer une fonction et implémenter un index sur fonction. À lire : [url= 11.7]http://www.postgresql.org/docs/9.1/static/indexes-expressional.html]"11.7. Indexes on Expressions"[url]A +
Dernière modification par SQLpro (23/12/2011 19:47:38)
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Pour ce qui est des colonnes calculées, les solutions sont actuellement limitées sous PG : il n'existe ni colonne calculée persistantes (calcul stocké avec les données)
Un trigger permet de le faire très bien.
ni index sur expression calculé,
C'est un index sur une expression, ce qui existe dans PostgreSQL, l'URL que vous donnez en étant la preuve (http://www.postgresql.org/docs/9.1/stat … ional.html).
ni de vues indexées
Inutile sur PostgreSQL tant que PostgreSQL ne gère pas les vues matérialisées.
Guillaume.
Hors ligne
Pour ce qui est des colonnes calculées, les solutions sont actuellement limitées sous PG : il n'existe ni colonne calculée persistantes (calcul stocké avec les données)
Un trigger permet de le faire très bien.
Pas tout à fait... une colonne calculée est généralement calculée par différence pour optimiser. Rien à voir avec un trigger qui est l'un des éléments les plus contre performant d'un SGBDR...
ni index sur expression calculé,
C'est un index sur une expression, ce qui existe dans PostgreSQL, l'URL que vous donnez en étant la preuve (http://www.postgresql.org/docs/9.1/stat … ional.html).
Non, c'est un index sur fonction... Ce n'est pas le même chose, car vous ne pouvez pas créer une colonne calculée (donc une expression de calcul) et l'indexer...
La différence, peut être subtile, vous aura sans doute échappée... Et là encore il y a une différence de coût, donc d'optimisation, importante...
ni de vues indexées
Inutile sur PostgreSQL tant que PostgreSQL ne gère pas les vues matérialisées.
Vue matérialisée et vues indexées sont la même chose. Oracle les appelle matérialisées et SQL Server vue indexées, mais c'est la même chose. Juste une différence de dénomination !
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Pas tout à fait... une colonne calculée est généralement calculée par différence pour optimiser. Rien à voir avec un trigger qui est l'un des éléments les plus contre performant d'un SGBDR...
Ne me faites pas dire ce que je n'ai pas dit. Je dis que c'est possible avec un trigger. C'est peut-être moins performant que l'implémentation native de tel ou tel moteur de bases de données, mais c'est possible.
Non, c'est un index sur fonction
Non, c'est un index sur une expression.
Guillaume.
Hors ligne
Pages : 1
