Discussion :

[selva15]

Bonjour,

Je souhaite diviser un champ dans une colonne en plusieurs colonnes comme le montre le schéma ci-dessous:

table actuelle:

-----------------------------------------------------------------------------------------------------------------
+ VIEWNAME + DEFINITION +
-----------------------------------------------------------------------------------------------------------------
+ Le nom de la vue + SELECT (...) FROM (...) WHERE (...) ORDER BY (...) +
+--------------------------------------------------------------------------------------------------------------+

Résultat Souhaité:
-----------------------------------------------------------------------------------------------------------------------------------
+ VIEWNAME + SELECT_CLAUSE + FROM_CLAUSE + WHERE_CLAUSE + ORDER_BY_CLAUSE +
----------------------------------------------------------------------------------------------------------------------------------
+ Le nom de la vue + les champs du select + Table + + +
+----------------------------------------------------------------------------------------------------------------------------------

J'aimerai savoir comment on peut créer une table en divisant la requête dans la définition de la vue en clause: select, from, where.

Merci par avance.

[SQLpro]

incompréhensible. Merci de respecter la charte de postage : http://www.developpez.net/forums/a69...gage-sql-lire/

A +

[escartefigue]

Bonjour,

La difficulté est qu'il peut y avoir de nombreux pièges, comment allez vous les éviter
- critères de recherche contenant des mots réservés (ex : WHERE colonne1 = ' FROM PARIS TO MADRID')
- nombre et types différents de jointures (à l'ancienne via le where, JOIN, comment allez vous les restituer dans votre colonne "FROM CLAUSE"
- SQL Dynamique éventuel
- intersect, except, union, comment les restituez vous
- requetes imbriquées (subselect)
etc...

En bref, ça sent l'usine à gaz

[selva15]

Bonjour,
Je vous remercie pour votre réponse.
en effet j'ai essayé le code suivant:

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
SELECT
VIEWNAME,
DEFINITION,
substr(DEFINITION, 7, strpos( DEFINITION, 'FROM')-7) as SELECT_CLAUSE,
substr(DEFINITION, strpos(DEFINITION,'FROM')+5, case when strpos( DEFINITION, 'WHERE') <> 0 then strpos( DEFINITION, 'WHERE') else strpos( DEFINITION, ';') end) as FROM_CLAUSE,
case when DEFINITION like '%WHERE%' then substr(DEFINITION, strpos(DEFINITION,'WHERE')+7, strpos( DEFINITION, ';'))  end as WHERE_CLAUSE
FROM _V_VIEW

ça donne exactement ce que je veux comme résultat sauf dans la clause From, il retourne également la clause du where!
J'essaye de voir s'il n'y a pas une méthode plus simple à le faire.
Merci:

[escartefigue]

Comme mentionné précédemment, si par exemple une de vos colonnes a un nom qui contient "FROM" alors votre solution ne fonctionnera pas
Plein d'autres raisons peuvent provoquer des résultats faux, cf. mon post précédent
Encore une fois, une solution répondant à tous les cas sera une véritable usine à gaz

[islamov2000]

Sous quel SGBD travailles tu?

[Rei Ichido]

Comme mentionné précédemment, si par exemple une de vos colonnes a un nom qui contient "FROM" alors votre solution ne fonctionnera pas

Pour moi, c'est le plus léger des soucis, d'autant plus qu'il peut se régler en recherchant sur 'FROM' entouré d'espaces / tabulations / retour à la ligne. Le vrai et principal problème à mon sens vient avec les sous-requêtes et donc la présence d'un WHERE décalé ... et ça, c'est quand même loin d'être anecdotique, parce que c'est quand même très fréquent dans une vue d'avoir des sous-requêtes ... sans compter le WITH ...

[selva15]

C'est sous IBM PureData (Netezza).
Oui je me suis rendue compte que la requête n'est pas valide dans le cas des vues avec des sous requêtes et des unions.

[escartefigue]

Pour moi, c'est le plus léger des soucis, d'autant plus qu'il peut se régler en recherchant sur 'FROM' entouré d'espaces / tabulations / retour à la ligne. Le vrai et principal problème à mon sens vient avec les sous-requêtes et donc la présence d'un WHERE décalé ... et ça, c'est quand même loin d'être anecdotique, parce que c'est quand même très fréquent dans une vue d'avoir des sous-requêtes ... sans compter le WITH ...

Oui, c'était l'objet de mon post #3