Discussion :

[cibouseb]

Bonjour,
J'ai une application Java avec laquelle je communique sur une base oracle grace à JDBC.

Lorsque que je crée une nouvelle ligne, j'aimerais savoir s'il est possible de récupérer le rowid de la nouvelle ligne.

Merci pour vos réponses
Seb

[rouardg]

Bonjour,

Une fois que tu as fait ton INSERT dans la table, il faut que tu refasses un SELECT ROWID FROM .... pour obtenir le ROWID.

Maintenant, si ce n'est pas indiscret, que veux-tu faire avec le ROWID ??? Parce qu'en général, personne ne l'utilise. C'est d'aileurs dangereux.

[cibouseb]

je l'utilise pour optimiser l'accés à un ligne de ma tabe
pour référencer une ligne c plus rapide de mettre son rowid que de mettre des " .... and ..... and ....".
Je parcours ma table ligne par ligne alors il me faut un référence pour savoir sur quelle ligne je suis.

J'ai quand meme un probleme il me renvoie le num en hexa au lieu des caracteres ...
Sais tu comment eviter cela ?

[SheikYerbouti]

Plus rapide et aussi plus dangereux.

La primary key est un moyen tout aussi efficace et qui ne risque pas de s'altérer au fil de certaines manipulations.

[rouardg]

Attends, attends, calme toi parce que là tu fais n'importe quoi !!!

pour référencer une ligne c plus rapide de mettre son rowid que de mettre des " .... and ..... and ....".

On ne référence jamais une ligne par son ROWID. Le ROWID est plutôt interne à Oracle. Il est stocké dans les index et sert à Oracle pour accéder aux données de la table.

Son format est hexadécimal. On peut le décoder à l'aide du package DBMS_ROWID. A ce moment là, tu sais dans quel datafile, dans quel n° de bloc et dans quelle ligne de ce bloc se situe tes données.

Pour accéder à tes données, tu es obligé de passer par des champs de ta table, d'où ta clause WHERE...AND ...AND. Si tu veux optimiser l'accès à une ligne, travaille sur la clé primaire, ou bien pose les bons index sur les bonnes colonnes de ta table. Et ne tombe pas dans le piège qui consiste à poser des index partout. La bonne métode, c'est de savoir sur quel volume de données on travaille, de voir la complexité de la requête, de tracer son plan d'exécution (il faut savoir le lire) et de ne le faire que si le temps de réponse n'est pas satisfaisant.

Pour info, un DBA est de temps en temps obligé de réorganiser la base pour résoudre des pbs de fragmentation. A ce moment-là, les tables ne sont plus au même endroit (datafile et bloc) et tes ROWID ne sont plus valables !!!

[cibouseb]

Mais est ce que cette réorganisation des tables peu se faire pendant l'execution d'une application sur cette table, c'est à dire pendant qu'une connexion est faites dessus(notamment une connexion JDBC), car en fait je l'utilise que lorsque je suis connecté et aucunement je le sauvegarde entre temps, des que la connexion est fermé le numero est perdu .

[rouardg]

Tout à fait. Je dirais même que, avec les versions d'Oracle, de plsu en plus de manipulations peuvent être faite on-line, c'est-à-dire base ouverte et avec les utilisateurs connectés et en train de travailler.

Par exemple, on peut reconstruire des index on-line.

Non crois-moi, si tu développes une application, n'utilise jamais le ROWID.

[cibouseb]

ok merci pour ce conseil.
En fait je cherche à tout pris à optimiser mes requetes car je travail sur de tres grande taille.

[rouardg]

L'optimisation des requêtes est un art et nécessite pas mal de connaisances.

Si je te parle de :
1 ) mode syntaxique ou mode coût (optimiseur fonctionnant en modeRBO ou CBO),
2 ) génération des statistiques,
3 ) index B*Tree, index bitmap ou index basé sur des fonctions,
4 ) jointure par tri-fusion (sort merge join), jointure par table de hachage
(hash join) et jointure par boucle imbriquée (nested loops),
5 ) index utilisé par unique, range ou full scan,
6 ) fast full scan index,
7 ) plan d'exécution d'une requête,
8 ) et si vraiment tu travaille sur du volume (table de 1 Go ou plus), alors partitionnements de table et/ou d'index, et parallélisme de requête.

Est-ce que ces termes te parlent ??? Si oui, lesquels ???

Si non, alors je suis au regret de te dire que tu n'as pas les connaissances pour optimiser tes requêtes.

Dans ce cas, il faudra te former. Jette un coup d'oeil sur l'article de Sheikyerbouti 'Optimisation Oracle'.

http://sgbd.developpez.com/

[cibouseb]

Si je connais les index, les jointures mais aprés tout le reste jsuis perdu.
Je ne suis qu'etudiant encore ... Et je n'ai jamais di que j'avais des connaissances pour optimiser les requetes, en fait je ne fais qu'essayer de les rendre plus rapide ...

Merci pour ton aide, je vais voir l'adresse.

[SheikYerbouti]

La solution souvent idéale pour un accès rapide à une table est de générer un clé primaire de type Number alimentée par une séquence qui correspond alors a une sorte de ROWID.
cette clé primaire (donc UNIQUE) permet de rédiger des requètes plus simples que celles utilisant le rowid.

[cibouseb]

Le probleme c'est que d'autre clé primaire existe deja, car l'application tourne deja sur une autre base de données (type fiechier txt) et il est quasi improbable de restructurer les tables (ca demanderais tro de boulot)

Mais merci qd mm pour ta solution

Bye

[SheikYerbouti]

Il s'agit d'un vrai faux problème.
si le but est de gagner du temps sur l'écriture d'une requète, la clause where peut-être copiée/collée, ou alors réutiliser une procédure existante...

Toutefois, l'on peut stocker le ROWID dans un varchar(30)

Code :

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

1
2
3
4
5
6
declare
RO	   varchar2(30);
begin
select rowid into RO from photos where identifiant=4;
update photos set legende=legende where rowid=RO;
end;

ce code simple fonctionne parfaitement.

[cibouseb]

je peu pas utiliser du PL/SQL car j'accede à ma base de donnée grace à une application JAVA et JDBC
Mais merci qd mm

[SheikYerbouti]

Peu importe.
Il s'agit juste de démontrer que le ROWID peut-être stocké dans une String, en hexa ou autre.

[cibouseb]

Ah dac
Merci pour ton aide.
Mais en fin de compte je ne peu pas l'utiliser ROWID car celui ci peu etre modifier par la base de données a tout moment

Bye
seb

[SheikYerbouti]

Je crois que c'est ce que nous tentions de vous dire depuis le début.

[cibouseb]

Merci a tous pour votre aide.
A bientot dur un autre sujet lol

Seb