Wie schlimm ist das ignorieren Oracle DUP_VAL_ON_INDEX-exception?

Ich habe eine Tabelle, wo ich die Aufnahme, wenn ein Benutzer angeschaut hat, ein Objekt mindestens einmal, also:

 HasViewed
     ObjectID  number (FK to Object table)
     UserId    number (FK to Users table)

Beiden Felder NICHT NULL sind, und bilden zusammen den Primärschlüssel.

Meine Frage ist, da ich egal wie oft jemand angezeigt hat, ein Objekt (nach dem ersten), habe ich zwei Möglichkeiten für das handling von Schneidplatten.

Ein SELECT count(*) ... und wenn keine Datensätze gefunden werden, fügen Sie einen neuen Datensatz.
Immer nur einen Datensatz einfügen, und wenn es wirft eine DUP_VAL_ON_INDEX Ausnahmen (die anzeigt, dass es schon so war, ein Rekord), ignorieren Sie es einfach.

Was ist die Kehrseite der Auswahl der zweiten option?

UPDATE:

Ich denke, der beste Weg, es zu setzen ist : "Ist der overhead, verursacht durch die Ausnahme, die schlimmer als der overhead, verursacht durch die anfängliche Auswahl?"

InformationsquelleAutor James Curran | 2008-12-08

Ich würde normalerweise einfach einfügen und trap die DUP_VAL_ON_INDEX-exception, da dies der einfachste code. Dies ist effizienter als die überprüfung auf die Existenz, bevor Sie. Ich denke nicht, dass dies zu tun, einen "schlechten Geruch" (furchtbarer Ausdruck!) weil die Ausnahme, die wir behandeln, ausgelöst durch Oracle - es ist nicht wie hebt Ihr Eure eigene Ausnahmen als flow-control-Mechanismus.

Dank Igor ' s Kommentar habe ich jetzt zwei verschiedene benchamrks auf dieser: (1) wo alle insert-versuche, außer der ersten, sind Duplikate, (2) wo alle Einsätze sind keine Duplikate. Die Realität liegt irgendwo zwischen den beiden Fällen.

Hinweis: tests an Oracle 10.2.0.3.0.

Fall 1: Überwiegend Duplikate

Es scheint, dass die meisten effizienter Ansatz (von einem signifikanten Faktor) ist zu prüfen, für die Existenz, WÄHREND einfügen:

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;
/

Ergebnisse (nach einmal ausgeführt, um zu vermeiden, die Analyse der Gemeinkosten):

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

Fall 2: keine Duplikate

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;
/

Ergebnisse:

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

In diesem Fall DUP_VAL_ON_INDEX gewinnt durch eine Meile. Beachten Sie die "select before insert" ist die langsamste, in beiden Fällen.

So scheint es, dass Sie sollten wählen Sie option 1 oder 3 entsprechend der relativen Wahrscheinlichkeit, fügt sein oder nicht-Duplikate.

Stellen Sie sicher, dass Sie ausführen, dass Tony benchmarks in Ihrer Umgebung. Ich weiß, wir hatten einige Probleme in einem 10.2.0.2 oder 10.2.0.3 Datenbank auf AIX, wo die Ausnahme Pfad wurde drastisch langsamer-- code, der funktionierte gut in 9.2 verlangsamte sich zu einem kriechen. Gab es einen patch um das Problem zu beheben, aber es war ein ärgernis.
Der test ist, wo es Duplikate sind. Was ist die Leistung, wie wenn die neue Zeile ist nicht eine doppelte (D. H. die mit der expliziten Prüfung ist noch überprüfen, aber der exception-handler müssen nicht kick).

InformationsquelleAutor Tony Andrews

1

Ich glaube nicht, dass es ein Nachteil für die zweite option. Ich denke, es ist ein absolut korrekter Verwendung der genannten Ausnahme, und es vermeidet die lookup-overhead.

InformationsquelleAutor kurosch
1

Versuchen?
```
SELECT 1
FROM TABLE
WHERE OBJECTID = 'PRON_172.JPG' AND
      USERID='JCURRAN'
```
Sollte es wieder 1, wenn es eines gibt, sonst NULL.

In Ihrem Fall sieht es sicher ignorieren, aber für die Leistung, die man vermeiden sollte-Ausnahmen auf dem gemeinsamen Weg. Eine Frage zu Fragen, "Wie Häufig werden die Ausnahmen sein?"
Paar genug, um zu ignorieren? oder so manch andere Methode sollte verwendet werden?
- Dies raise exception NO_DATA_FOUND wenn es keine Zeile, es wird nicht NULL zurückgegeben.
- Yep. Ich denke, sql, und es ist ein pl/sql-Frage.
InformationsquelleAutor EvilTeach
0

In der Regel -, Ausnahme-Behandlung ist langsamer; aber wenn es passieren würde, nur selten, dann würden Sie vermeiden den Aufwand der Abfrage.

Ich denke, es hängt hauptsächlich von der Frequenz der Ausnahme, aber wenn die Leistung wichtig ist, würde ich vorschlagen, einige benchmarking mit beiden Ansätzen.

Generell, die Behandlung von gemeinsamen Veranstaltungen als Ausnahme ist ein schlechter Geruch; aus diesem Grund konnte man sehen, auch aus einer anderen Sicht.

Wenn es eine Ausnahme ist, dann sollte es behandelt werden, als die Ausnahme - und dein Vorgehen ist korrekt.

Wenn es ein common event, dann sollten Sie versuchen, explizit behandeln - und dann prüfen, ob der Datensatz bereits eingefügt.
- Fangen die DUP_VAL_ON_INDEX-exception wird dann schneller prüfen für Existenz - wie ich zeigen wird, in meine Antwort. Wie bei den "schlechten Geruch", ich sehe nichts falsch daran, trapping eine Ausnahme ausgelöst, die von Oracle und Behandlung entsprechend - dies unterscheidet Erhöhung Ihrer EIGENEN Ausnahme für einen nicht-Fehler.
- Ich bin nicht einverstanden. Der name "exception" sagt uns, Ausnahmen sollten nicht verwendet werden, die für den normalen Programmablauf, egal Ihrer Herkunft. Ansonsten ist es ein schlechter Geruch. Außerdem werden Ihre Antworten zeigen, dass die Verhütung die Ausnahme ist der Schnellste Weg (siehe Ergebnisse für "Test ob Datensatz existiert, während einfügen").
- Nein ist es nicht, es zeigt das genaue Gegenteil! Es ist lächerlich, nicht das beste Werkzeug für den job, nur weil Sie nicht wie der "Geruch" der seinem Namen!!
InformationsquelleAutor rob
0

IMHO ist es am besten zu gehen mit der Option 2: Andere als das, was bereits gesagt worden ist, sollten Sie überlegen, thread-Sicherheit. Wenn man mit option 1 und, Wenn mehrere threads Ihre PL/SQL-block, dann ist es möglich, dass zwei oder mehr threads Feuer wählen Sie in der gleichen Zeit und zu dieser Zeit gibt es keine Aufzeichnungen, diese werden am Ende alle führenden threads einfügen und Sie erhalten unique-constraint-Fehler.

InformationsquelleAutor user961954

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.