il est tard.. et jsuis fatigué..
kkun pourrait mexpliquer l'interet des vues... car on me demande
si je pourrait pas utiliser une vue a la place de mes jointures...
bref... je dois dire si oui ou non, je peux passer par une vue a la place de mes jointure...  
kkun pourrait m'eclairer sur l'utilisation des vues... merci

wouatouwouatou a écrit a écrit : il est tard.. et jsuis fatigué.. kkun pourrait mexpliquer l'interet des vues... car on me demande si je pourrait pas utiliser une vue a la place de mes jointures... bref... je dois dire si oui ou non, je peux passer par une vue a la place de mes jointure...   kkun pourrait m'eclairer sur l'utilisation des vues... merci

 
c'est pas que je sois méchant, mais FAIS UNE RECHERCHE
le sujet a été abordé il n'y a pas si longtemps (eh oui, même si tu es fatigué )

ben c'est pas toujours possible de faire une jointure
(par exemple jointure externe de t1 vers t2 puis jointure externe de t2 vers t3) donc la vue peut résoudre le pb.
 
un inconvénient des vues, c'est la place mémoire nécessaire

jai fais la recherche mais... c pas encore tres clair
Je dois etre trop fatigué D

en fait, jai une big requete (9ko )..
et les select... ben ya plein de fonction d'agregat..surtout des decode...
Je me demandais si via une vue, ce serait interessant de les mettre dedans kom colonne... et quapres dans mes select, jai plus ka faire le nom de ma colonne...
paske jen ai plein des truc kom ca...
Et le pire, c que dans ma requete ya plein de sous requete...
alors... comment faire une vue  ? Jai pas trop piger le but de la vue je crois...
jespere ke c la chaleur... (on a plus de clim.. )

une vue c'est tout simplement un raccourci pour une requête, ça se défini par un ordre sql
create view v (nomdecolonnes) as select ....
après, ça s'utilise comme une table ...

en fait, je me demandais surtout s'il etait judicieux de faire une vue pour eviter de se trimbaler les decode et toutes les autres fonctions du genre to_char...
Est ce kon peut faire une vue en definissant une colonne avec de telle fontions ?
 
Et surtout, si ca se fait... perso, jai plus limpreion ke c de la bidouille.. mais jespere ke non...

[edit]--Message édité par wouatouwouatou--[/edit]

Euh.. c encore moi
Comment kon fait pour mettre un paramettre dans une vue ?
Jai rien trouvé dessus dans ma doc...
zauriez pas un indice...
car jai une sous requete ke jappelle souvent.. mais elle depend d'un parametre.... alors je trouve pas comment la mettre en vue..
Au fait, c possible de la mettre en vue ??
une petite reponse siouplez...
 
p.s: je precise qu'une fois le parametre trouvé, la requete est la meme

comme je l'ai déjà dit, c'est un raccourci, donc ça ne prend pas plus de mémoire ni plus de taille, c'est juste pour pas avoir à faire ça dans plusieurs requêtes. et c'est pas du bricolage. pas de paramètres, faut juste mettre dans l'ordre select la clause where qui convient exactement comme si tu faisais un select sur une table. mais fais quand même gaffe aux index, car si c'est mal fait, ça peut ramer grave

donc, a chaque fois que mon parametre change... je devrais refaire un create or replace view ?
ca craignos..

mais non, c'est tout le contraire que je dit ...
 
ex  
create view v1(c1,c2) as select a.c1,b.c2 from a,b where a.val = b.val
 
après :
 
select c1 from v1 where c2 = 'xxx';
 
voilà

L'intérêt d'une vue est de pouvoir avoir accès à des données issues d'une requête complexe sans devoir se taper la dite requête à chaque fois, et avec une mise à jour permanente (sachant que les données d'une vue sont mises à jour dès que les données d'une des tables dont dépend la vue sont elles-mêmes mises à jour).
 
Chez nous, on a une vue portant sur... 16 tables (8 réellement) (max autorisé par Sybase, je ne les remercie pas sur ce coup-là), et heureusement qu'elle est là!!!
 
Par contre, on n'utilise pas de paramètres.
 
Selon la fréquence d'evolution des paramètres, un script de "mise à jour de la vue" (un peu paradoxal) est sans doute utilisable.

hmm...  
moi ce serait plutot un truc du genre:
 

 
tu vois ? c pas tout a fait pareil ke toi

salut fred999 !!!
 
C en rapport a ma big requete.. tu ten rappelles ??
J'en ai chié pendant plus de 2 semaines.. et maintenant il veulent ke jutilise les vues.. alors j'etudie (o reetudie le pb).
Il me semblait ke les vues navait pas dinteret justement a coz du fait ke jai un parametre ...

Je m'en souviens vaguement...
 
2 semaines de (presque) perdues, bon c'est la loi du travail (dite de Dilbert) qui veut parfois ça.
 
Franchement, j'ai du mal à imaginer l'intérêt d'une vue avec paramètres.
 
Ils trouvent ton traitement trop long?

non.. c meme pas ca...  
elle prend 2 voire 3 sec.. 'seulement'
Mais c au nivo forme.. elle fait 10ko...
je te raconte pas la tete kelle a .. si tu la voyait tu halucinerai
Je pense ke c surtout pour la lisibilité.. il ont peur de se la payer pour la maintenance.. et surtout sil veulent la comprendre et rajouter des trucs... J'ai meme fait un chtit dessin representant les sous requetes et leurs liens ... mais bon...
La, il fo ke je leur dise si une vue c judicieux ou pas... alors..
P.S: je te la mailerai si tu veux la voir meme si c pas trop legal

[edit]--Message édité par wouatouwouatou--[/edit]

tu fais
 
create or replace view ma_vue as  
select a.c1, b.c1, a.c2  
from a, b  
where a.val=b.val  
 
et tu fais ensuite select from ma_vue where c2 = voilou

Euh.. jai oublie de preciser ke ma requete est un peu plus compliquée ke ca..  
elle a un group by et un having... et kom si ca suffisait pas, le select contient aussi un max et un count ...
D
enfin, tu vois la galere... le C2 je peux pas le mettre dans le select du fait kil y a un group by...

wouatou > messages privés

fred999 > c mailé
 
sinon.. la requete que je veux mettre en vue...
et en gras, c le parametre...

[edit]--Message édité par wouatouwouatou--[/edit]

ça correspond à quoi ce affected_user_id ???
tu le met en plus dans la requete et le group by, vu que tu veux sélectionner dessus, ça pose pas de pb !!!

comprend plus ...
tu pourrais pas me donner un chtit exemple.. depuis create view à select.. from view...

CREATE VIEW v_(a,b,c,d)
AS
SELECT  
o.oper_pers_id,  
o.affected_user_id,
max(o.operation_date) date_relance,  
count(o.oper_id)  
FROM  
operation o,  
operation_type ot,  
operation_group og,  
status s  
WHERE o.oper_realisation_date<=sysdate  
AND not(o.oper_realisation_date is null)  
AND o.oper_last_status_id=s.status_id  
AND o.oper_type_id=ot.oper_type_id  
AND ot.oper_group_id=og.oper_group_id  
AND lower(og.oper_group_description)='relance'  
AND lower(s.status_short_label)='lancé'  
GROUP BY  
o.oper_pers_id,
o.affected_user_id
HAVING
count(o.oper_id)=1
 
select * from v_ where b = 28

ah.. oki oki..
jessaie de suite... merci

Au fait... c'est de l'Oracle ce truc! Sacrilège!!!
 
PS : terrifiante cette requête.

Fred999 > Rigolo va !!!! Oracle Powaaaaaaaaa

ça c'est rien comme requête, j'en ai déjà vu avec 20 tables et 200 lignes. case imbriqués en série, sous select, group by avec 15 colonnes ....
 
:eek2::eek2::eek2:

hihihi.. tu parlais sans doute de la requete complete fredo
jai presque terminé les vues... mais jsais pas si c kom ca kon fait alors..

ddr555 > on se fait un troll Oracle / Sybase?
 
Effectivement, je parlais de la requête complète.
 
waoutou > T'as pas mis UNE ligne de commentaire, tes alias de tables sont pire que monosyllabiques (une seule lettre).  
Comment veux-tu que j'y comprenne quelque chose?
 
Heureusement c'est bien indenté

vi.. c normal... paske la requete ke ta c celle de base...
elle est normalement utilisée dans du code java.. et ya des concatenation de conditions un peu partout... alors les alias (yen a pas tant ke ca) doivent garder cette tete (kestion pratique) ...  
hihi.. c pas une requete de pd
Bref, au final, ta plus (au sens bcp plus) de AND dans les where et la c pire ke tout D
Si javais commenté, ca taurais pas trop aidé.. par contre je peux tenvoyer le schema que jai fais de la requete...
 
P.S: jai fini les vues... et ca marche !!!

[edit]--Message édité par wouatouwouatou--[/edit]

j'oubliais.. en remplacant les sous requetes telle kelle, ca me fait 11 vues...
mais, je vais essayer de diminuer ca a 5 ...

En fait, c'est plus des tables temporaires que des vues que tu utilises, non?
 
N'oublie pas qu'une vue est "permanente"!

ca y est je tai mailé le schema...
an fait les vues sont ce kil me fo.. car les tables c pas top...
une vue ne faisant ke des references au donnees existantes alors ke pour les table , on doit copier ces donnees...
Bref, avec la technique de ddr555 ... en mettant la colonne de parametrage dans le select et les group by.. c nickel !!!
 
Je remonte ainsi jusqu'a la vue globale ki utilise les vues ds sous requetes de base ...

je viens de mapercevoir kavec les options ke turajoute a la requete... dynamiquement.. ben l'utilisation des vues c pas possible !!
sinon, fo les refaire a chaque fois...
Et une journee de paumé encore

Bin.... Pour moi, par nature, une vue ne doit pas avoir de paramètres, elle ne fait que refléter un état de ta base de données.
 
D'où la notion de tables temporaires : je pense que l'important dans ton truc est d'améliorer la lisibilité, sans grosse perte de perfs, pour faciliter la maintenance.
 
(putain je me mets à parler comme mon chef, manque plus que le franglais)

Je suis tout à fait d'accord avec Fred999    : des tables temporaires (qui sont droppées / créées à chaque exécution du script) améliorent souvent grandement les performances, et en tout cas permettent une maintenance et une lisibilité sans équivalent avec une grosse requête. En plus l'évolutivité ultérieure est encore mieux assurée, puisque l'on sait ce que l'on obtient dans chaque table temporaire => on peut ne modifier qu'un seul script parmi les x nécessaires, on sait ainsi parfaitement comment les autres se comporteront (pas d'obligation de tout se retaper le code si ça ne marche pas ).
 
Sinon une idée pour les parmètres : ça ne serait pas possible d'avoir une table de paramètres, avec une seule colonne comportant les valeurs désirées, et d'utiliser cette colonne en jointure partout où le paramètre intervient ?
Comme cela il n'y aurait besoin de n'intervenir qu'une seule fois pour changer le parmaètre, et ce changement serait automatiquement répercuté dans les scripts, avec la jointure, non ?

 
Je m'en veux presque de ne pas y avoir pensé. Surtout que, dans la base du bureau, au milieu des 136 tables, il y en a une qui a pour nom... "parametre"
 
Et hop, à ranger dans les "bonnes idées à utiliser un jour".

sinon, tu peux créer une procédure stockée qui crée ta vue de manière dynamique, mais c'est une usine à gaz niveau maintenance. arrêtez de parler de paramètres à une vue, c'est pas une procédure/fonction, juste un RACCOURCI

un exemple de procédure pour exécuter une commande sql texte, bien pratique par exemple pour éxécuter un truncate que tu peux faire directement que sous sqlplus :
 
PROCEDURE Execute_Str (
        Str_  LONG)
    IS
        cur_ INTEGER;
        ret_ INTEGER;
    BEGIN
        Print_SQL(Str_) ;  --
        cur_ := dbms_sql.open_cursor;
        dbms_sql.parse(cur_, Str_, dbms_sql.v7);
        ret_ := dbms_sql.execute (cur_);
        dbms_sql.close_cursor(cur_);
        IF ret_ IS NULL THEN
            DBMS_Output.Put('No');
        ELSE
            DBMS_Output.Put(ret_);
        END IF;
        DBMS_Output.Put_Line(' lines affected.');
    EXCEPTION
        WHEN OTHERS THEN
            Print_SQL(Str_);
            RAISE;
    END;
peut être à changer très légèrement avec oracle v8, mais j'en sais pas plus

J'ai pas tout pigé sur votre table de parametres...
ca doit etre le debut de semaine D
 
Mon pb avec les parametres, c kils font intervenir plusieurs tables... bref, je vois vraiment pas koment je peux les mettre dans une tables... il interviennent, selon le parametre, dans des sous requetes differentes et se rapportent a des tables differentes... Bref, perso.. je pense ke le gars il a mal jaugé le truc... car il voulait en une seule requete (pas de p.s.) obtenir tout plein d'info sur plusieurs tables... faisant intervenir des conditions monstres (srtout les tri par groupe et date.)