Comment le mauvais est ignorant Oracle DUP_VAL_ON_INDEX exception?

Je devrais normalement il suffit de l'insérer et de piéger le DUP_VAL_ON_INDEX exception, comme c'est le plus simple à coder. C'est plus efficace que la vérification de l'existence du fichier avant de l'insérer. Je ne pas envisager de faire une "mauvaise odeur" (horrible expression!) parce que l'exception nous nous occupons est soulevée par Oracle - ce n'est pas comme élever vos propres exceptions en tant que flux de mécanisme de contrôle.

Grâce à Igor commentaire que j'ai maintenant exécuter deux benchamrks sur ceci: (1) lorsque toutes les tentatives d'insertion à l'exception de la première sont des doublons, (2) où tous les inserts ne sont pas des doublons. La réalité se situe entre les deux cas.

Remarque: les tests effectués sur Oracle 10.2.0.3.0.

Cas 1: la Plupart des doublons

Il semble que l'approche la plus efficace (par un facteur significatif) est de vérifier l'existence lors de l'insertion d':

prompt 1) Check DUP_VAL_ON_INDEX
begin
   for i in 1..1000 loop
      begin
         insert into hasviewed values(7782,20);
      exception
         when dup_val_on_index then
            null;
      end;
   end loop
   rollback;
end;
/

prompt 2) Test if row exists before inserting
declare
   dummy integer;
begin
   for i in 1..1000 loop
      select count(*) into dummy
      from hasviewed
      where objectid=7782 and userid=20;
      if dummy = 0 then
         insert into hasviewed values(7782,20);
      end if;
   end loop;
   rollback;
end;
/

prompt 3) Test if row exists while inserting
begin
   for i in 1..1000 loop
      insert into hasviewed
      select 7782,20 from dual
      where not exists (select null
                        from hasviewed
                        where objectid=7782 and userid=20);
   end loop;
   rollback;
end;
/

Résultats (après avoir exécuté une fois pour éviter de l'analyse des frais généraux):

1) Check DUP_VAL_ON_INDEX

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.54
2) Test if row exists before inserting

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.59
3) Test if row exists while inserting

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.20

Cas 2: pas de doublons

prompt 1) Check DUP_VAL_ON_INDEX
begin
   for i in 1..1000 loop
      begin
         insert into hasviewed values(7782,i);
      exception
         when dup_val_on_index then
            null;
      end;
   end loop
   rollback;
end;
/

prompt 2) Test if row exists before inserting
declare
   dummy integer;
begin
   for i in 1..1000 loop
      select count(*) into dummy
      from hasviewed
      where objectid=7782 and userid=i;
      if dummy = 0 then
         insert into hasviewed values(7782,i);
      end if;
   end loop;
   rollback;
end;
/

prompt 3) Test if row exists while inserting
begin
   for i in 1..1000 loop
      insert into hasviewed
      select 7782,i from dual
      where not exists (select null
                        from hasviewed
                        where objectid=7782 and userid=i);
   end loop;
   rollback;
end;
/

Résultats:

1) Check DUP_VAL_ON_INDEX

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.15
2) Test if row exists before inserting

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.76
3) Test if row exists while inserting

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.71

Dans ce cas DUP_VAL_ON_INDEX gagne par un mile. Note le "select avant d'insérer" est le plus lent dans les deux cas.

Il semble donc que, vous devez choisir l'option 1 ou 3 en fonction de la probabilité relative de l'insère être ou ne pas être des doublons.

OriginalL'auteur Tony Andrews

Essayer ce?

SELECT 1
FROM TABLE
WHERE OBJECTID = 'PRON_172.JPG' AND
      USERID='JCURRAN'

Il doit retourner 1, si il y en a un là, sinon NULL.

Dans votre cas, il semble sûr d'ignorer, mais pour la performance, il convient d'éviter d'exceptions sur le chemin commun. Une question à poser la question "Comment la volonté commune des exceptions?"
Assez peu d'ignorer? ou tant d'autre méthode doit être utilisée?

OriginalL'auteur EvilTeach

À mon humble avis il est préférable d'aller avec l'Option 2: d'Autres que ce qui est déjà dit, vous devriez envisager de la sécurité des threads. Si vous allez à l'option 1 et Si plusieurs threads d'exécution de votre PL/SQL bloc alors il est possible que deux ou plusieurs fils de feu sélectionnez dans le même temps, et à ce moment il n'existe aucun enregistrement, ce sera la fin de leader sur tous les threads d'insérer et vous obtiendrez contrainte unique erreur.

OriginalL'auteur user961954