Gestion des Tables d'Object

Bonjour,
j'ai un petit soucis sur la gestion/compréhension des tables d'Objet
dans le contexte suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production   Create or Replace Type Repertoire AS OBJECT ( ID NUMBER, Propriétaire Ref Disque, Nom Varchar2(255), Pére Ref Repertoire );   Create Table Repertoires of Repertoire( Pére With ROWID SCOPE IS Repertoires, Propriétaire With ROWID SCOPE IS Disques, CONSTRAINT PK_Repertoires primary key(ID) );   Alter Table Repertoires ADD CONSTRAINT FK_Repertoires_PERE FOREIGN KEY (Pére) REFERENCES Repertoires ON DELETE CASCADE;   create index I_Pere_Repertoires on REPERTOIRES(pére);

---

Alors que la table est une table d'objet ( Row object), j'ai l'erreur suivante :

Code:

---

1 2 3 4 5

ORA-02332 cannot create index on attributes of this column Cause: An attempt was made to create an index on an attributes of an object type column. Action: Do not specify the index on the attribute.

---

Si j'inverse l'ordre de création, ie l'index avant la contrainte je n'ai pas de msg d'erreur.
La premiére démarche me semble théoriquement valide ?
Quelqu'un a-t-il une explication ?

Merci

Code:

---

1 2 3 4

Alter Table Repertoires ADD CONSTRAINT FK_Repertoires_PERE FOREIGN KEY (Pére) REFERENCES Repertoires ON DELETE CASCADE;

---

tu mets une foreign key qui référence la table sur laquelle tu crées ta foreign key ???

Oui, c'est une relation pére-fils.
J'essaie de reproduire ce qu'il est possible de faire en relationnel :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

( générée sous AMC )   create table REPERTOIRE ( OID INTEGER not null, REPNOM VARCHAR2(255) not null, NOMUNITE VARCHAR2(255) not null, PERE INTEGER, constraint PK_REPERTOIRE primary key (OID), );   alter table REPERTOIRE add constraint FK_REPERTOI_PERE_REPERTOI foreign key (PERE) references REPERTOIRE (OID);

---

effectivement ...

voici ce que j'ai trouvé dans la doc

Citation:

---

Restrictions on Foreign Key Constraints
None of the columns in the foreign key can have datatype LOB, LONG, LONG RAW, VARRAY, NESTED TABLE, OBJECT, BFILE, or REF, or TIMESTAMP WITH TIME ZONE. However, the primary key can contain a column of TIMESTAMP WITH LOCAL TIME ZONE.

---

or ta colonne est bien de type object non ?

Bonjour,
la colonne PERE est de type pointeur =REF= RAW.

Si je modifie son type en Objet, le message est

Code:

---

1 2 3 4 5

ORA-02267 column type incompatible with referenced column type Cause: The datatype of the referencing column is incompatible with the datatype of the referenced column. Action: Select a compatible datatype for the referencing column.

---

Ce message me renvoie effectivement vers la restriction que tu cites.
Alors que l'instruction de déclaration de la FK d'origine ne me renvoie aucune erreur.

C'est vrai que cela semble incohérent de placer une FK sur une colonne qui est déjà une référence.
La clause Scope IS permet une contrainte d'intégrité référentielle "partiel".

Ici l'objectif est de gérer les contraintes d'intégrité référentielle (supprimer tous les objet dépendants ).
On peut effectivement les coder avec des triggers.


Le RO est donc une avancée dans le passé :)

Mais le PB vient de l'index.
j'ai un peu avancé de ce coté là.
Si je déclare l'index puis la contrainte cela fonctionne, enfin je n'ai pas de msg d'erreur ie 'ça tombe en marche' :wink: , mais dans OEM la colonne nommée 'pére' n'est pas présente dans la liste des colonnes de l'index en question ! 8O
Si je supprime la contrainte et fait un refresh dans OEM, la colonne 'pére' réapparait dans la liste des colonnes de l'index en question.

Ceci est confirmé par le résultat de l'exécution d' explain plan sur une requête utilisant la colonne pére.
Avec la contrainte

Code:

---

1 2 3

TABLE ACCESS FULL REPERTOIRES TABLE ACCESS BY INDEX ROWID REPERTOIRES

---

Sans la contrainte

Code:

---

1 2 3

TABLE ACCESS BY INDEX ROWID REPERTOIRES INDEX RANGE SCAN I_PERE_REPERTOIRES

---

On peut donc déclarer une contrainte FK sur une colonne de type REF d'une table d'objet mais à partir de là on ne peut plus référencer cette colonne dans un index ?

Voilà, j'essaie de comprendre comment fonctionne le RO sous Oracle, qu'est-ce que l'on peut faire avec, connaitre ses avantages et ses inconvénients...
Merci

Citation:

---

PRIMARY KEY constraints cannot be specified for REF columns

---

Application Developer's Guide - Object-Relational Features / CHAPITRE 2

??? je t'avoue que j'ai du mal à m'y retrouver ...

Euh la je suis d'accord j'ai du mal à suivre.

Tu dis que une fois que tu as créer l'index, si tu rajoutes la contrainte, la colonne disparait de l'index???

Peut tu vérifier non pas avec OEM mais directement à la mimine dans les tables USER_TABLES, USER_INDEX, user_ind_columns

Citation:

---

Envoyé par Laurent Dardenne

...On peut donc déclarer une contrainte FK sur une colonne de type REF d'une table d'objet mais à partir de là on ne peut plus référencer cette colonne dans un index ?
...

---

Par contre, je crois qu'il est tout à fait possible de créer un index composite sur les colonnes de l'objet...

Salut,

Citation:

---

Envoyé par Marc Musette

Citation:

---

PRIMARY KEY constraints cannot be specified for REF columns

---

Application Developer's Guide - Object-Relational Features / CHAPITRE 2

---

Effectivement Marc, si je déclare une PK sur une colonne REF Oracle me parle du pays de l'Objet d'une maniére trés claire ;-).
.. mais je n'ai pas de pb de PK.

Cette Doc je ne l'ai pas encore lu en long et en large, mais je l'ai lu en long dans un premier temps :-)
Et pour simplifier l'apprentissage du RO, uniquement la doc de la 8i. Imagine avec les possibilités de la 9i ...

Pour moi cette doc "Application Developer's Guide - Object-Relational Features " présente le RO sous les meilleurs jours.
Ce que j'essaie de faire n'est pas complexe, ce domaine est pour moi( nous ? ), simplement "Terra incognita".

Citation:

---

Envoyé par Marc Musette

??? je t'avoue que j'ai du mal à m'y retrouver ...

---

Citation:

---

Envoyé par helyos

Euh la je suis d'accord j'ai du mal à suivre.

---

Je vous comprends.Je vous rappelle le nombre de ligne du code d'origine : 16.

Mon schéma de base :
Un disque contient 0-N Répertoire
Un répertoire contient 0-N répertoires-fils
Un répertoire contient 0-N Fichiers
J'ai pris ce cas simple, qui s'avére "pas simple" à mettre en oeuvre en RO. ( ie pas les compétences/connaisances ?)
J'utilise la possibilité du CONNECT BY pour gérer un arbre hiérarchique.
J'essaie d'optimiser l'accés aux données par la création d'index sur des tables d'objets.

Est-ce moi qui fait n'importe quoi ?
OUI : Sur la contrainte FK d'une colonne de type REF, effectivement j'ai un doute.
Si je demande de l'aide sur ce forum c'est justement pour le lever ce doute (gestion des contraintes d'intégrité en RO ).

OUI : Oracle me permet de faire du "spaghetti sauce RO" ? DBA préparez vos mouchoirs ! ( les pro ont du stocke :-) )

NON : comment se fait il que ces problématiques de base ne soient pas clairement explicités dans la documentation ?
Le RO c'est fantastique ! ( create view RO as select Marketing ... )
...

Citation:

---

Envoyé par helyos

Tu dis que une fois que tu as créer l'index, si tu rajoutes la contrainte, la colonne disparait de l'index???
Peut tu vérifier non pas avec OEM mais directement à la mimine dans les tables USER_TABLES, USER_INDEX, user_ind_columns

---

J'ai modifié la déclaration d'index :

Code:

---

1 2 3

Create index I_NomPereOID_Repertoires on REPERTOIRES(Nom,pére);

---

Table crée
Index crée
Contrainte non déclarée "Alter Table Repertoires ADD CONSTRAINT FK_Repertoires_PERE FOREIGN KEY (Pére)
REFERENCES Repertoires ON DELETE CASCADE " .

Code:

---

1 2 3 4 5 6 7 8

SQL> select COLUMN_NAME From user_ind_columns Where table_name='REPERTOIRES' and INDEX_NAME='I_NOMPEREOID_REPERTOIRES';   COLUMN_NAME -------------------------------------------------------------------------------- NOM PÉRE

---

La colonne PÉRE est présente
( la visu sous OEM est en phase)

Code:

---

1 2 3 4 5

SQL> Alter Table Repertoires 2 ADD CONSTRAINT FK_Repertoires_PERE FOREIGN KEY (Pére) 3 REFERENCES Repertoires ON DELETE CASCADE; Table modifiée.

---

Code:

---

1 2 3 4 5 6 7 8

SQL> select COLUMN_NAME from user_ind_columns where table_name='REPERTOIRES' and INDEX_NAME='I_NOMP EREOID_REPERTOIRES' ;   COLUMN_NAME -------------------------------------------------------------------------------- NOM "PÉRE"

---

La colonne PÉRE est présente mais entre guillements.
( la visu sous OEM n'est pas en phase, la colonne Pére est absente)

Code:

---

1 2 3

SQL> Alter Table Repertoires DROP CONSTRAINT FK_Repertoires_PERE; Table modifiée.

---

Contrainte "FK_... " supprimée.

Code:

---

1 2 3 4 5 6 7 8

SQL> select COLUMN_NAME from user_ind_columns where table_name='REPERTOIRES' and INDEX_NAME='I_NOMP EREOID_REPERTOIRES';   COLUMN_NAME -------------------------------------------------------------------------------- NOM PÉRE

---

La colonne PÉRE est présente
( la visu sous OEM est en phase, la colonne Pére est présente )

Citation:

---

Envoyé par SheikYerbouti

Citation:

---

Envoyé par Laurent Dardenne

...On peut donc déclarer une contrainte FK sur une colonne de type REF d'une table d'objet mais à partir de là on ne peut plus référencer cette colonne dans un index ?
...

---

Par contre, je crois qu'il est tout à fait possible de créer un index composite sur les colonnes de l'objet...

---

Je confirme SheikYerbouti.

Donc pour en revenir à mon PB
Peut on déclarer une contrainte FK sur une colonne de type REF d'une table d'objet ?
Et peut on référencer cette "colonne contrainte" dans un index ?

QQ peut-il vérifier ce comportement sur un serveur ?
Merci

en tout cas la doc n'est pas la meilleure qui soit ...

même Tom Kyte annonce clairement qu'il n'utilise pas les types objets pour stocker des données ... il préfère les bonnes vieilles tables et n'utilise que les types etc au niveau programmation

et ce problème de guillements ... ça c'est vraiment fort ...

bon courage Laurent !!!

Citation:

---

Envoyé par Marc Musette

en tout cas la doc n'est pas la meilleure qui soit ...

---

A mon avis il manque une compilation des informations relative au RO qui sont disséminées sur l'ensemble de la documentation.

Citation:

---

Envoyé par Marc Musette

même Tom Kyte annonce clairement qu'il n'utilise pas les types objets pour stocker des données ... il préfère les bonnes vieilles tables et n'utilise que les types etc au niveau programmation

---

Oui, j'ai lu ça sur le site Ask Tom. Il préconise d'utiliser le relationnel pour la persistence des données, et les objets (notamment les vues Objet) pour leur manipulation.
Et le coté performance n'est pas négligeable ...

Au vu des petits soucis que je rencontre, je vais donc suivre ses conseils :wink:

Citation:

---

Envoyé par Marc Musette

et ce problème de guillements ... ça c'est vraiment fort ...

---

Est-ce courant sur Oracle ce type "d'effet de bord" et ce sans message d'avertissement ? à moins que cela soit un bug ?

Merci

Pour info :
Dans un premier temps je souhaitais optimiser ce curseur:

Code:

---

1 2 3 4 5 6

Cursor Parcourt_Fils_Pére(Départ Repertoire) IS Select Value(R) From Repertoires R Where R.nom<>'ROOT' Connect by prior R.Pére=ref(R) Start with Value(R)=Départ;

---

Mais dans la déclaration de l'index je ne savais pas comment spécifier l'objet lui même ( ie la ligne d'une table d'objet )

Code:

---

1 2 3

Create index I_PereOID_Repertoires on REPERTOIRES(pére, ?);

---

SELF ne fonctionne que sous PL/SQL.
Et par hasard j'ai trouvé cela dans la doc de SQL*Loader :
il existe une pseudo colonne nommée "SYS_NC_OID$" qui référence l'objet lui même.

On peut donc améliorer la requête "Connect by prior R.Pére=ref(R) " d'une table d'objet par la déclaration de l'index suivant :

Code:

---

1 2 3

Create index I_PereOID_Repertoires on REPERTOIRES(pére, SYS_NC_OID$);

---

Citation:

---

These objects are stored in tables, known as object tables, that have columns
corresponding to the attributes of the object. The object tables have an additional
system-generated column, called SYS_NC_OID$, that stores system-generated
unique identifiers (OIDs) for each of the objects in the table. Columns in other tables
can refer to these objects by using the OIDs.

---

Attention, CONNECT BY PRIOR n'est intéressant que si on cherche une hiérarchie qui va plus loin que père-fils, dans le cas contraire il vaut mieux joindre la table avec elle-même ;)

Merci,
mais la profondeur peut être importante
"C:\Documents and Settings\Laurent\Application Data\Adobe\Acrobat\6.0\Preferences"
C'est pour ça que je tente d'optimiser le recherche récursive, mais c'est pas gagné !

Apres observation pour les guillemets.

cela viens du fait que tu utilises un é dans le nom de ta table ce que personnellement je te deconseille fortement ( de plus meme Oracle ne préconise pas l'utilisation de caractère accentué)

pour une table c'est
30 caractères (de a jusqu'a z, et tout les chiffres)
doit commencer par une lettre
et les qq caractères spéciaux.

Donc Oracle à du rajouter implicitement les " pour etre en mesure d'interpreter le é.

De plus OEM à quelque probleme avec les accents et les guillemets (il en rajoute autour des noms d'objets donc "Pére" est reconnue par ""Pére"" ..., c'est pour cela que je t'avais demander de regarder à la mimine.

Si tu veux corriger le pb renomme ta colonne en PERE et non pas Pére

De plus si tu dois créer une table je te conseilles fortement de le faire à la main car OEM n'étant "que" (pardon Oracle) un gros générateur de code, il entoure tout les noms d'objets de " ce qui peut poser problemes suite à l'utilisation de caractères spéciaux, voir des pb de majuscule minuscule.

Pour ce qui est de ton autre probleme, pourrais tu donner l'état d'avancement? As tu changer ta méthode pour utiliser la bonne vielle méthode donnée par Tom, ou as tu conservés ton objet?

De plus qu'est ce qui te pose probleme dans l'optimisation de la requete?

Citation:

---

Envoyé par helyos

Apres observation pour les guillemets.

cela viens du fait que tu utilises un é dans le nom de ta table ce que personnellement je te deconseille fortement ( de plus meme Oracle ne préconise pas l'utilisation de caractère accentué)
Si tu veux corriger le pb renomme ta colonne en PERE et non pas Pére

---

Effectivement pour SqlLoader j'avais renommé mes tables comportant des accents, mais je n'avais pas modifié les noms de champs.
Malheureusement le probléme persiste.

Code:

---

1 2 3 4 5 6 7 8 9

SQL> select COLUMN_NAME From user_ind_columns 2 Where table_name='REPERTOIRES' and INDEX_NAME='I_NOMPEREOID_REPERTOIRES';   COLUMN_NAME -------------------------------------------------------------------------------- NOM "PERE" SYS_NC_OID$

---

En regardant dans OEM la colonne nommé 'SYS_NC_OID$' est de type RAW mais la colonne 'PERE' de type REPERTOIRE ( donc objet ).
Je suppose qu'OEM ne fait pas de distinguo entre un objet et une référence d'objet.
Et l'extrait de la doc Oracle que cite Marc Musette, parle de restriction sur une colonne de type OBJET et REF. %-(
Il y a une contradiction entre la doc et la possibilité de déclarer ce type de FK et lors de la création d'un index Oracle me signale une erreur 8O

Citation:

---

Envoyé par helyos

De plus si tu dois créer une table je te conseilles fortement de le faire à la main car OEM

---

Tout est déjà scripté.

Citation:

---

Envoyé par helyos

Pour ce qui est de ton autre probleme, pourrais tu donner l'état d'avancement? As tu changer ta méthode pour utiliser la bonne vielle méthode donnée par Tom, ou as tu conservés ton objet?

De plus qu'est ce qui te pose probleme dans l'optimisation de la requete?

---

Pour le moment, je reste sur les tables objets ensuite j'utiliserais les vues objet.

Le pb c'est l'insertion de masse des données, pour chaque ligne à insérer via SQLoader je dois rechercher le point d'insertion dans l'arbre( ie l'arborescence d'un disque dur). De plus les données en entrée ne sont pas ordonnée.
Je pense ajouter une colonne qui contient le chemin complet pour chaque noeud, c'est pas trés élégant .
J'ai regardé du coté du site SQL de Frédéric Brouard sur les arbres intervallaires mais dans un premier temps je regarde les possibilités de l'instruction 'Connect by'.

Oki je commence à mieux cerner ton probleme (pour ce qui est de l'index je suis en pleine recherche, je viens de trouver le bug 2451999 qui est en relation avec ce probleme

Citation:

---

ORA-2332 creating TEXT index on XDBURITYPE / URITYPE / HTTPURITYPE column

---

Le problème c'est que c'est censé etre corrigé en 9.2.0.4

)

Bon donc ton probleme c'est l'insertion en masse des chemins .

Pourrais tu donner un exemple du fichier que tu importes?

Car il y a aurait peut etre moyen de faire les importations autrement

Merci pour l'info du bug :D

voici qq exemples

nom de domaine; nom de machine;FullPath;FileName;TYPE ( Fichier,Repertoire)

Code:

---

1 2 3 4 5 6 7 8 9

Dom_Test;AMD2800;C:\Delphi;;R Dom_Test;AMD2800;C:\Delphi7;;R Dom_Test;AMD2800;C:\Dev_ORA;;R Dom_Test;AMD2800;C:\Delphi\Aprg\0-nt\;jgntcmps.zip;F Dom_Test;AMD2800;C:\Delphi\Aprg\0-nt\;mailslot-Messanger.zip;F Dom_Test;AMD2800;C:\Delphi\Aprg\0-nt\;Nt-getusergroup.txt;F Dom_Test;AMD2800;C:\Delphi\Aprg\0-nt\;ntuser.zip;F Dom_Test;AMD2800;C:\Delphi\Aprg\0-nt\;old-citrix.zip;F

---

J'utilise une table temporaire sur laquelle j'ai posé un trigger qui se charge de créer les objets.
N'ayant pu les charger sous SQL*Loader ...

Code:

---

1 2 3 4 5 6 7 8

Create Table DispatchObjet( DisqueDomain Varchar2(15), DisqueMachine Varchar2(15), PathNom Varchar2(255), FileNom Varchar2(255), ObjetType Character );

---

Je peux créer un soft sous Delphi pour gérer cela "plus facilement", mais je préfére une solution Oracle et script NT.
On n'a pas tjr un compilo sous la main.

Pourquoi ne pas tout faire en PL/SQL avec une petite procédure?
Moi je pense que ca serait le plus efficace. Tu charges ton fichier avec SQL Loader (ou utl_file) et tu traites chaques chemin avec du pl.

C'est que je fais déjà
Methode d'un objet Disque:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68

Member Function Insert_Path(Path IN Varchar2) Return Repertoire is -- Recherche et insére une suite de répertoire dans l'arborescence RépertoireCourant Repertoire; Ref_RépertoireCourant Ref Repertoire; Ref_Disque Ref Disque;   Tampon Varchar2(257); FindPath Varchar2(257);   PosBackSlash Integer; IsInsert Boolean;   Begin If Path is NULL or IsPath(Path)=False Then Raise_Application_Error(-20000,'Le nom de chemin '||Path||' est mal formé.'); End If; Tampon:=Substr(Path,3+1); -- Supprime le début du path 'A:\' Tampon:=Rtrim(Tampon,'\'); -- RemoveBackSlash RépertoireCourant:=SELF.Get_Root(); -- Démarre la lecture à partir du ROOT Ref_Disque:=Self.Get_Ref; -- Récupére un pointeur sur le disque courant IsInsert:=False; -- Démarre en mode recherche   if RépertoireCourant is NULL Then Insert Into Repertoires R -- Insére le root Values (Repertoire(IDRepertoires.NextVal,Ref_Disque,Path,'ROOT',NULL)) Returning Value(R) Into RépertoireCourant; End IF;   If Tampon is NULL -- Path=Root Then Return(RépertoireCourant); End If;   Begin -- Parcourt le chemin sous-répertoire par sous-répertoire. Loop PosBackSlash:=InStr(Tampon,'\',1); -- Recherche la premiére occurence de '\' If PosBackSlash<>0 Then FindPath:=Substr(Tampon,1,PosBackSlash-1); -- Extrait le répertoire courant sans le Backslash Tampon:=Substr(Tampon,PosBackSlash+1); -- Supprime le répertoire courant avec le Backslash Else FindPath:=Tampon; -- C'est donc le dernier répertoire End IF; Begin If IsInsert=False -- Si mode Recherche , recherche le dernier répertoire contenue dans Findpath Then Select value(R) Into RépertoireCourant from Repertoires R -- Recherche le fils de nom Findpath WHERE R.Nom=FindPath and DeRef(R.pere)=RépertoireCourant; End If; Exception WHEN NO_DATA_FOUND THEN IsInsert:=True; -- On passe en mode création End;   If IsInsert -- Le dernier repertoire recherché n'existe pas. Then Insert Into Repertoires R -- Insére le répertoire courant Values (Repertoire(IDRepertoires.NextVal,Ref_Disque,FindPath,Path,RépertoireCourant.Get_Ref)) Returning Value(R) Into RépertoireCourant; End If;   If PosBackSlash=0 -- Il n'y a plus de sous répertoires, on sort de la boucle Then Exit; End IF; End loop; End; Return( RépertoireCourant); -- Renvoie le dernier trouvé ou le dernier inséré End;

---

C'est une ébauche et je ne suis pas certain que cela soit la bonne approche.
Mais la gestion des arbre n'est pas aisée en sql si je ne me trompe...

Personnelement je pense que n'importe quel type d'approche est bon.

Maintenant la gestion d'un arbre en pl n'est pas plus difficile qu'avec un autre language. Le tout est de bien penser l'algo avant.

Maintenant apères avoir regardé ton code, je trouve cette ébauche un peu plus compliquée que si tu avais utilisé une bonne vieille table (mais ceci n'est que mon avis.)

Ensuite certaines parties sont peut etre un peut trop recursive mais cela peut etre arrangé

Maintenant question: Ou est ce que cela pose probleme dans ton code?
Lenteur ou autre?

Souhaites tu revoir une autre méthode (avec de bonnes vieilles table :) )

Citation:

---

Envoyé par helyos

Ensuite certaines parties sont peut etre un peut trop recursive mais cela peut etre arrangé

Maintenant question: Ou est ce que cela pose probleme dans ton code?
Lenteur ou autre?

---

Je n'utilise pas la récursivité.
C'est plus un pb de lenteur.
Mais la configuration des tables (pctfree,...) n'est pas gérée.
Je vais regarder de ce coté là et utiliser dbms_profiler pour vérifier ce qui est lent.
peut être une répétition de code et/ou de lecture de donnée.

Citation:

---

Envoyé par helyos

Souhaites tu revoir une autre méthode (avec de bonnes vieilles table :) )

---

Je peux effectivement utiliser des tables relationnel en lieu et place de tables objets.

Mais ma problématique est la suivante :
trouver le + rapidement possible dans l'arborescence le point d'insertion d'un nouveau répertoire ( son pére).
Si ce nouveau répertoire n'existe pas trouver le point d'insertion le plus proche ( création d'une 'branche' ).

Je ne sais pas utiliser 'Connect by' pour ce type de requête, ie
trouve-moi le ROWID du chemin ('C:\temp\rep1\zz\XX')

Par contre pour l'affichage de l'arborescence 'Connect by' répond trés bien au besoin.

Oki je vois ce que tu veux dire
Je vais regarder si je peux te faire une sorte d'algo qui ferait les recherches et insertion dans la table d'arbre (sur le principe de table normales :) ).

Par contre je vois pas trop l'interet du pctfree, pctused et autre car dans ton cas c plus des inserts donc au niveau tuning ca changera pas grand chose ou alors tres peu.

Alors voila le code dont je t'ai parlé.

Création des bonnes vieilles tables.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

create table T_PATH ( PATH VARCHAR2(257), PERE ROWID );   create table T_FILE ( PATH ROWID, FILENAME VARCHAR2(257) );

---

Création des index

Code:

---

1 2 3

create index IDX1 on T_PATH (PATH,PERE); create index PATHIDX on T_PATH (PATH); create index PEREIDX on T_PATH (PERE);

---

Ensuite création de mon petit package.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72

CREATE OR REPLACE PACKAGE BODY pathpack IS   FUNCTION check_path(p_tampon VARCHAR2, p_pere ROWID DEFAULT NULL) RETURN ROWID IS TYPE cur_dyn IS REF CURSOR; curpere cur_dyn; v_rowid ROWID; v_requete VARCHAR2(500); BEGIN IF p_pere IS NULL THEN v_requete := 'SELECT ROWID FROM t_path WHERE pere IS NULL AND path =''' || REPLACE(p_tampon, '''', '''''') || ''''; ELSE v_requete := 'SELECT ROWID FROM t_path WHERE pere =''' || p_pere || ''' AND path =''' || REPLACE(p_tampon, '''', '''''') || ''''; END IF; --Comme il n'est cencé n'y avoir que 1 seul répertoire avec ce nom la à la racine pas --besoin de boucle OPEN curpere FOR v_requete; FETCH curpere INTO v_rowid; CLOSE curpere; IF v_rowid IS NULL THEN --Le repertoire n'existe pas je l'ajoute INSERT INTO t_path VALUES (p_tampon, p_pere) RETURNING ROWID INTO v_rowid; COMMIT; RETURN v_rowid; ELSE --Le repertoire existe je renvoie son rowid RETURN v_rowid; END IF; END;   PROCEDURE insertpath IS CURSOR cur_test IS SELECT * FROM dispatchobjet; tampon VARCHAR2(257); v_rowidpere ROWID; v_temppath VARCHAR2(257); v_date DATE := SYSDATE; BEGIN FOR rec IN cur_test LOOP tampon := substr(lower(rec.pathnom), 3 + 1); tampon := rtrim(tampon, '\'); --Si c que un repertoire IF instr(tampon, '\') = 0 AND rec.objettype = 'R' THEN v_rowidpere := check_path(tampon); ELSE --Si y a plusieur sous repertoire LOOP EXIT WHEN instr(tampon, '\') = 0; --On prend le premier repertoire v_temppath := substr(tampon, 1, instr(tampon, '\') - 1); v_rowidpere := check_path(v_temppath, v_rowidpere); tampon := substr(tampon, instr(tampon, '\') + 1); END LOOP; --on fini le dernier repertoire v_rowidpere := check_path(tampon, v_rowidpere); IF rec.objettype = 'F' THEN INSERT INTO t_file VALUES (v_rowidpere, rec.filenom); COMMIT; END IF; END IF; v_rowidpere := NULL; END LOOP; htp.prn((SYSDATE - v_date) * 1440); END;   END pathpack;

---

Donc tu remplis ta table intermediaire dispatchobjet.

Puis tu lances la procédure insertpath.

Je stocke directement les rowid pour la relation pere fils (je n'ai pas fait les contraintes)

Il met 4 minutes pour 21544 lignes sur un P3 1ghz.

Dis moi si ca t'aide ou pas?

Citation:

---

Envoyé par helyos

Dis moi si ca t'aide ou pas?

---

Je regarde ça.

Le ROWID est persistant aprés un Import /Export ?
Merci

Oula c'est une tres bonne question pour le rowid je vais faire des recherches.

Bonjour,
Voici ce que j'ai trouvé sur Metalink.

Merci a tous.

Citation:

---

Bug No. 3064929
Filed 23-JUL-2003
Updated 19-AUG-2003
Product Oracle Server - Enterprise Edition V7
Product Version 9.2.0.3.0
Platform Generic
Platform Version No Data
Database Version 9.2.0.3.0
Affects Platforms Generic
Severity Severe Loss of Service
Status Closed, not feasible to fix
Base Bug N/A
Fixed in Product Version No Data

Problem statement:

ORA-2332 CREATING AN INDEX ON A REF COLUMN IN 9.2.0.3

*** 07/23/03 06:48 am ***
TAR:
----
3262208.999
.
PROBLEM:
--------
ORA-2332 error trying to create an index on a REF COLUMN in 9.2.0
This same operation works succesfully in 9.0.1

DIAGNOSTIC ANALYSIS:
--------------------
Reproduced in 9.2.0
The index is created succesfully in 9.0.1.4

WORKAROUND:
-----------
None

RELATED BUGS:
-------------
BUG 2744943

REPRODUCIBILITY:
----------------
Every time in 9.2.0.x
It works succesfully in 9.0.1.

TEST CASE:
----------
drop table tab_obj_Sections;
drop table tab_obj_Departments;
drop type typ_obj_Section;
drop type typ_obj_Department;
.
CREATE TYPE typ_obj_Department is object
(
Code VARCHAR2(10),
Nom VARCHAR2(50)
) NOT FINAL;
/
CREATE TABLE tab_obj_Departments OF typ_obj_Department
(
CONSTRAINT pk_Departments PRIMARY KEY(Code)
) OIDINDEX oid_Departments
/
CREATE TYPE typ_obj_Section is object
(
Code VARCHAR2(10),
Nom VARCHAR2(50),
RefDepartment REF typ_obj_Department
) NOT FINAL;
/
CREATE TABLE tab_obj_Sections OF typ_obj_Section
(
CONSTRAINT fk_Sections_Dept FOREIGN KEY(RefDepartment) REFERENCES
tab_obj_Departments
) OIDINDEX oid_Sections
/
CREATE UNIQUE INDEX pk_Sections ON tab_obj_Sections (RefDepartment.Code)
/

This last statement reports this error in 9.2.0.1
ORA-2332: cannot create index on attributes of this column
but works fine in 9.0.1.4

STACK TRACE:
------------
NA
.
SUPPORTING INFORMATION:
-----------------------
24 HOUR CONTACT INFORMATION FOR P1 BUGS:
----------------------------------------
DIAL-IN INFORMATION:
--------------------

IMPACT DATE:
------------
After upgrade from 9.0.1 to 9.2 customer is not able to create this kind of
indexes, so this problem is affecting seriously their environment.
.
*** 07/23/03 08:43 am *** (CHG: Sta->16 Asg->NEW OWNER)
*** 07/24/03 01:55 am *** (CHG: Sta->11 Asg->NEW OWNER)
*** 07/24/03 01:55 am ***
*** 07/24/03 10:55 am *** (CHG: Asg->NEW OWNER)
*** 07/24/03 10:55 am ***
*** 08/01/03 06:12 am *** (CHG: Asg->NEW OWNER)
*** 08/06/03 11:03 pm ***
*** 08/06/03 11:04 pm *** (CHG: Sta->44)
*** 08/19/03 03:12 am ***
*** 08/19/03 03:14 am *** (CHG: Sta->84)
*** 08/19/03 03:14 am ***
The pk-based reference have packed representation. Thus we don't have the cloumn information for each attribute. As per base, this behavior is okay as we.
are trying to create a index on the type attrbute (RefDepartment.Code).So ora-2332 is the right error message. The fact that it used to work in 9014 was an undesirable behavior.

To resolve this bug, enhancement is required in the product. Closing this
bug as not feasible to fix. File a seperate enhancement request.
Raised Enhancement request for this BUG against Bug number 3104504.

---