Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
JKB
Le 07-06-2010, ? propos de Question sur les vues sous PostgreSQL, Etienne ?crivait dans fr.comp.applications.sgbd :
Salut
've
Je crée une vue toute bête disons CREATE VIEW ma_vue AS SELECT * FORM ma_table;
Pourquoi est-ce que cette vue est transformée en CREATE VIEW ma_vue AS select ma_table.col1, ma_table.col2, ... FROM ma_table;
En gros, y a t_il un moyen pour que ma vue reste SELECT * et pas SELECT de tous les champs au moment où elle a été crée?
En gros aussi, quel est le problème ?
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 07-06-2010, ? propos de
Question sur les vues sous PostgreSQL,
Etienne ?crivait dans fr.comp.applications.sgbd :
Salut
've
Je crée une vue toute bête disons
CREATE VIEW ma_vue AS SELECT * FORM ma_table;
Pourquoi est-ce que cette vue est transformée en
CREATE VIEW ma_vue AS select ma_table.col1, ma_table.col2, ... FROM
ma_table;
En gros, y a t_il un moyen pour que ma vue reste
SELECT *
et pas SELECT de tous les champs
au moment où elle a été crée?
En gros aussi, quel est le problème ?
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 07-06-2010, ? propos de Question sur les vues sous PostgreSQL, Etienne ?crivait dans fr.comp.applications.sgbd :
Salut
've
Je crée une vue toute bête disons CREATE VIEW ma_vue AS SELECT * FORM ma_table;
Pourquoi est-ce que cette vue est transformée en CREATE VIEW ma_vue AS select ma_table.col1, ma_table.col2, ... FROM ma_table;
En gros, y a t_il un moyen pour que ma vue reste SELECT * et pas SELECT de tous les champs au moment où elle a été crée?
En gros aussi, quel est le problème ?
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Eric Masson
JKB writes:
'Lut,
En gros aussi, quel est le problème ?
Lorsque tu fais un alter table sur la table originelle pour ajouter un champ, tu es obligé de récréer la vue pour prendre le nouveau champ en compte, je ne sais pas si c'est un problème, mais il y a une étape de plus.
-- Subject: écrivez moi vite , besoin d'explication je vient d'acquérir cette chose formidable que l'on appelle Internet , je recherche quelqu'un pouvant m'expliquer comment faire -+- VJ in GNU : Et t'as essayé la vaiselle avec les pieds ? -+-
JKB <knatschke@koenigsberg.fr> writes:
'Lut,
En gros aussi, quel est le problème ?
Lorsque tu fais un alter table sur la table originelle pour ajouter un
champ, tu es obligé de récréer la vue pour prendre le nouveau champ en
compte, je ne sais pas si c'est un problème, mais il y a une étape de
plus.
--
Subject: écrivez moi vite , besoin d'explication
je vient d'acquérir cette chose formidable que l'on appelle Internet ,
je recherche quelqu'un pouvant m'expliquer comment faire
-+- VJ in GNU : Et t'as essayé la vaiselle avec les pieds ? -+-
Lorsque tu fais un alter table sur la table originelle pour ajouter un champ, tu es obligé de récréer la vue pour prendre le nouveau champ en compte, je ne sais pas si c'est un problème, mais il y a une étape de plus.
-- Subject: écrivez moi vite , besoin d'explication je vient d'acquérir cette chose formidable que l'on appelle Internet , je recherche quelqu'un pouvant m'expliquer comment faire -+- VJ in GNU : Et t'as essayé la vaiselle avec les pieds ? -+-
JKB
Le 07-06-2010, ? propos de Re: Question sur les vues sous PostgreSQL, Eric Masson ?crivait dans fr.comp.applications.sgbd :
JKB writes:
'Lut,
En gros aussi, quel est le problème ?
Lorsque tu fais un alter table sur la table originelle pour ajouter un champ, tu es obligé de récréer la vue pour prendre le nouveau champ en compte, je ne sais pas si c'est un problème, mais il y a une étape de plus.
C'est bien ce que j'avais compris dans la question initiale. Je ne vois pas vraiment comment faire autrement puisque le '*' doit être traité dans l'interprète de ligne...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 07-06-2010, ? propos de
Re: Question sur les vues sous PostgreSQL,
Eric Masson ?crivait dans fr.comp.applications.sgbd :
JKB <knatschke@koenigsberg.fr> writes:
'Lut,
En gros aussi, quel est le problème ?
Lorsque tu fais un alter table sur la table originelle pour ajouter un
champ, tu es obligé de récréer la vue pour prendre le nouveau champ en
compte, je ne sais pas si c'est un problème, mais il y a une étape de
plus.
C'est bien ce que j'avais compris dans la question initiale. Je ne
vois pas vraiment comment faire autrement puisque le '*' doit être
traité dans l'interprète de ligne...
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 07-06-2010, ? propos de Re: Question sur les vues sous PostgreSQL, Eric Masson ?crivait dans fr.comp.applications.sgbd :
JKB writes:
'Lut,
En gros aussi, quel est le problème ?
Lorsque tu fais un alter table sur la table originelle pour ajouter un champ, tu es obligé de récréer la vue pour prendre le nouveau champ en compte, je ne sais pas si c'est un problème, mais il y a une étape de plus.
C'est bien ce que j'avais compris dans la question initiale. Je ne vois pas vraiment comment faire autrement puisque le '*' doit être traité dans l'interprète de ligne...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Etienne
Le 07/06/2010 14:44, JKB a écrit :
C'est bien ce que j'avais compris dans la question initiale. Je ne vois pas vraiment comment faire autrement puisque le '*' doit être traité dans l'interprète de ligne...
il est bien possible qu'il 'ya ai pas de solution. en fait mon problème vient du fait que j'ai un script qui synchronise deux schéma de base de données.
par convention, j'ai considéré que les champs commençant par _ était des variables de test (sur le serveur de test). et donc je ne les synchronize pas. ca marche très bien, sauf que j'ai une vue sur ma base de dev qui converti mon CREATE VIEIW AS SELECT *.
Bon c'est pas très grave, je vais améliorer le script pour regénérer la vue en fonction des attributs qui la compose. C'est jsute que s'il y avait eu un moyen...
Etienne.
Le 07/06/2010 14:44, JKB a écrit :
C'est bien ce que j'avais compris dans la question initiale. Je ne
vois pas vraiment comment faire autrement puisque le '*' doit être
traité dans l'interprète de ligne...
il est bien possible qu'il 'ya ai pas de solution.
en fait mon problème vient du fait que j'ai un script qui synchronise
deux schéma de base de données.
par convention, j'ai considéré que les champs commençant par _ était des
variables de test (sur le serveur de test).
et donc je ne les synchronize pas.
ca marche très bien, sauf que j'ai une vue sur ma base de dev qui
converti mon CREATE VIEIW AS SELECT *.
Bon c'est pas très grave, je vais améliorer le script pour regénérer la
vue en fonction des attributs qui la compose.
C'est jsute que s'il y avait eu un moyen...
C'est bien ce que j'avais compris dans la question initiale. Je ne vois pas vraiment comment faire autrement puisque le '*' doit être traité dans l'interprète de ligne...
il est bien possible qu'il 'ya ai pas de solution. en fait mon problème vient du fait que j'ai un script qui synchronise deux schéma de base de données.
par convention, j'ai considéré que les champs commençant par _ était des variables de test (sur le serveur de test). et donc je ne les synchronize pas. ca marche très bien, sauf que j'ai une vue sur ma base de dev qui converti mon CREATE VIEIW AS SELECT *.
Bon c'est pas très grave, je vais améliorer le script pour regénérer la vue en fonction des attributs qui la compose. C'est jsute que s'il y avait eu un moyen...
Etienne.
Sebastien Lardiere
Le 07/06/2010 14:08, Etienne a écrit :
Salut
Je crée une vue toute bête disons CREATE VIEW ma_vue AS SELECT * FORM ma_table;
Pourquoi est-ce que cette vue est transformée en CREATE VIEW ma_vue AS select ma_table.col1, ma_table.col2, ... FROM ma_table;
En gros, y a t_il un moyen pour que ma vue reste SELECT * et pas SELECT de tous les champs au moment où elle a été crée?
Non, ça n'est pas possible, la requête est réécrite lors du create view.
Une vue est une relation, on doit connaître la liste des colonnes et les types de chacune de ces colonnes.
En fait, je ne vois pas de bonne raison de laisser un select * dans une vue. Au même titre que je considère comme une mauvaise pratique le fait de mettre un select * dans le code source d'une application -> toujours spécifier ce qu'on cherche !
-- Sébsatien
Le 07/06/2010 14:08, Etienne a écrit :
Salut
Je crée une vue toute bête disons
CREATE VIEW ma_vue AS SELECT * FORM ma_table;
Pourquoi est-ce que cette vue est transformée en
CREATE VIEW ma_vue AS select ma_table.col1, ma_table.col2, ... FROM
ma_table;
En gros, y a t_il un moyen pour que ma vue reste
SELECT *
et pas SELECT de tous les champs
au moment où elle a été crée?
Non, ça n'est pas possible, la requête est réécrite lors du create view.
Une vue est une relation, on doit connaître la liste des colonnes et les
types de chacune de ces colonnes.
En fait, je ne vois pas de bonne raison de laisser un select * dans une
vue. Au même titre que je considère comme une mauvaise pratique le fait
de mettre un select * dans le code source d'une application -> toujours
spécifier ce qu'on cherche !
Je crée une vue toute bête disons CREATE VIEW ma_vue AS SELECT * FORM ma_table;
Pourquoi est-ce que cette vue est transformée en CREATE VIEW ma_vue AS select ma_table.col1, ma_table.col2, ... FROM ma_table;
En gros, y a t_il un moyen pour que ma vue reste SELECT * et pas SELECT de tous les champs au moment où elle a été crée?
Non, ça n'est pas possible, la requête est réécrite lors du create view.
Une vue est une relation, on doit connaître la liste des colonnes et les types de chacune de ces colonnes.
En fait, je ne vois pas de bonne raison de laisser un select * dans une vue. Au même titre que je considère comme une mauvaise pratique le fait de mettre un select * dans le code source d'une application -> toujours spécifier ce qu'on cherche !
-- Sébsatien
Etienne
Le 07/06/2010 16:23, Sebastien Lardiere a écrit :
En fait, je ne vois pas de bonne raison de laisser un select * dans une vue. Au même titre que je considère comme une mauvaise pratique le fait de mettre un select * dans le code source d'une application -> toujours spécifier ce qu'on cherche !
En fait c'est surtout une question de facilité !!! Mais bon dans mon cas présent effectivement j'aurai solutionné mon problème si j'avais écrit les vues à la main.
Etienne
Le 07/06/2010 16:23, Sebastien Lardiere a écrit :
En fait, je ne vois pas de bonne raison de laisser un select * dans une
vue. Au même titre que je considère comme une mauvaise pratique le fait
de mettre un select * dans le code source d'une application -> toujours
spécifier ce qu'on cherche !
En fait c'est surtout une question de facilité !!!
Mais bon dans mon cas présent effectivement j'aurai solutionné mon
problème si j'avais écrit les vues à la main.
En fait, je ne vois pas de bonne raison de laisser un select * dans une vue. Au même titre que je considère comme une mauvaise pratique le fait de mettre un select * dans le code source d'une application -> toujours spécifier ce qu'on cherche !
En fait c'est surtout une question de facilité !!! Mais bon dans mon cas présent effectivement j'aurai solutionné mon problème si j'avais écrit les vues à la main.
Etienne
SQLpro
Le SELECT * a été un long débat dans la norme SQL et ce qui est ressortit de le discussion était qu'il ne devait pas être utilisé en production, mais uniquement pour la mise au point du code (test de requêtes). PostGreSQL applique à juste titre la norme au pied de la lettre et tant mieux ! Une vue dont la définition serait fluctuante ne peut avoir que des inconvénient, notamment en matière de performances (recompilation et perte des plans mis en cache si table modifiée...).
A +
Etienne a écrit :
Salut
Je crée une vue toute bête disons CREATE VIEW ma_vue AS SELECT * FORM ma_table;
Pourquoi est-ce que cette vue est transformée en CREATE VIEW ma_vue AS select ma_table.col1, ma_table.col2, ... FROM ma_table;
En gros, y a t_il un moyen pour que ma vue reste SELECT * et pas SELECT de tous les champs au moment où elle a été crée?
Merci Etienne
-- Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66 Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
Le SELECT * a été un long débat dans la norme SQL et ce qui est
ressortit de le discussion était qu'il ne devait pas être utilisé en
production, mais uniquement pour la mise au point du code (test de
requêtes).
PostGreSQL applique à juste titre la norme au pied de la lettre et tant
mieux !
Une vue dont la définition serait fluctuante ne peut avoir que des
inconvénient, notamment en matière de performances (recompilation et
perte des plans mis en cache si table modifiée...).
A +
Etienne a écrit :
Salut
Je crée une vue toute bête disons
CREATE VIEW ma_vue AS SELECT * FORM ma_table;
Pourquoi est-ce que cette vue est transformée en
CREATE VIEW ma_vue AS select ma_table.col1, ma_table.col2, ... FROM
ma_table;
En gros, y a t_il un moyen pour que ma vue reste
SELECT *
et pas SELECT de tous les champs
au moment où elle a été crée?
Merci
Etienne
--
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Le SELECT * a été un long débat dans la norme SQL et ce qui est ressortit de le discussion était qu'il ne devait pas être utilisé en production, mais uniquement pour la mise au point du code (test de requêtes). PostGreSQL applique à juste titre la norme au pied de la lettre et tant mieux ! Une vue dont la définition serait fluctuante ne peut avoir que des inconvénient, notamment en matière de performances (recompilation et perte des plans mis en cache si table modifiée...).
A +
Etienne a écrit :
Salut
Je crée une vue toute bête disons CREATE VIEW ma_vue AS SELECT * FORM ma_table;
Pourquoi est-ce que cette vue est transformée en CREATE VIEW ma_vue AS select ma_table.col1, ma_table.col2, ... FROM ma_table;
En gros, y a t_il un moyen pour que ma vue reste SELECT * et pas SELECT de tous les champs au moment où elle a été crée?
Merci Etienne
-- Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66 Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
SQLpro
Et pour compléter ma propre réponse, si vous avez des colonnes de même nom résultant d'une jointure naturelle sur le lien d'association, la vue serait susceptible de ne plus fonctionner, car comme toute table (et une vue est une table d'un type particulier) il faut qu'il y ait unicité des noms des colonnes dans la vue.
A +
SQLpro a écrit :
Le SELECT * a été un long débat dans la norme SQL et ce qui est ressortit de le discussion était qu'il ne devait pas être utilisé en production, mais uniquement pour la mise au point du code (test de requêtes). PostGreSQL applique à juste titre la norme au pied de la lettre et tant mieux ! Une vue dont la définition serait fluctuante ne peut avoir que des inconvénient, notamment en matière de performances (recompilation et perte des plans mis en cache si table modifiée...).
A +
Etienne a écrit :
Salut
Je crée une vue toute bête disons CREATE VIEW ma_vue AS SELECT * FORM ma_table;
Pourquoi est-ce que cette vue est transformée en CREATE VIEW ma_vue AS select ma_table.col1, ma_table.col2, ... FROM ma_table;
En gros, y a t_il un moyen pour que ma vue reste SELECT * et pas SELECT de tous les champs au moment où elle a été crée?
Merci Etienne
-- Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66 Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
Et pour compléter ma propre réponse, si vous avez des colonnes de même
nom résultant d'une jointure naturelle sur le lien d'association, la vue
serait susceptible de ne plus fonctionner, car comme toute table (et une
vue est une table d'un type particulier) il faut qu'il y ait unicité des
noms des colonnes dans la vue.
A +
SQLpro a écrit :
Le SELECT * a été un long débat dans la norme SQL et ce qui est
ressortit de le discussion était qu'il ne devait pas être utilisé en
production, mais uniquement pour la mise au point du code (test de
requêtes).
PostGreSQL applique à juste titre la norme au pied de la lettre et tant
mieux !
Une vue dont la définition serait fluctuante ne peut avoir que des
inconvénient, notamment en matière de performances (recompilation et
perte des plans mis en cache si table modifiée...).
A +
Etienne a écrit :
Salut
Je crée une vue toute bête disons
CREATE VIEW ma_vue AS SELECT * FORM ma_table;
Pourquoi est-ce que cette vue est transformée en
CREATE VIEW ma_vue AS select ma_table.col1, ma_table.col2, ... FROM
ma_table;
En gros, y a t_il un moyen pour que ma vue reste
SELECT *
et pas SELECT de tous les champs
au moment où elle a été crée?
Merci
Etienne
--
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Et pour compléter ma propre réponse, si vous avez des colonnes de même nom résultant d'une jointure naturelle sur le lien d'association, la vue serait susceptible de ne plus fonctionner, car comme toute table (et une vue est une table d'un type particulier) il faut qu'il y ait unicité des noms des colonnes dans la vue.
A +
SQLpro a écrit :
Le SELECT * a été un long débat dans la norme SQL et ce qui est ressortit de le discussion était qu'il ne devait pas être utilisé en production, mais uniquement pour la mise au point du code (test de requêtes). PostGreSQL applique à juste titre la norme au pied de la lettre et tant mieux ! Une vue dont la définition serait fluctuante ne peut avoir que des inconvénient, notamment en matière de performances (recompilation et perte des plans mis en cache si table modifiée...).
A +
Etienne a écrit :
Salut
Je crée une vue toute bête disons CREATE VIEW ma_vue AS SELECT * FORM ma_table;
Pourquoi est-ce que cette vue est transformée en CREATE VIEW ma_vue AS select ma_table.col1, ma_table.col2, ... FROM ma_table;
En gros, y a t_il un moyen pour que ma vue reste SELECT * et pas SELECT de tous les champs au moment où elle a été crée?
Merci Etienne
-- Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66 Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
