What are the surrogate key and row_number( )

Question

what are the surrogate key and row_number( ) function, and why do not we always make the row_number a primary key in the table.

Answer 1

Mohannad,
we just try to safe your efforts and to prevent common
mistakes you can make.
Look here.
Your requirement is to avoid gaps in sequence.
OK. But it means you HAVE to lock your sequence
exclusively until you commit transaction.
Also, it means you have to rollback sequence
number to original value if you rollback you
entire transaction.
SQL> create table my_tab (id number);
&nbsp
Table created.
&nbsp
SQL> create table numer_tab (id number);
&nbsp
Table created.
&nbsp
SQL> insert into numer_tab values(0);
&nbsp
1 row created.
&nbsp
SQL>  create or replace trigger
  2   tr_no_gap
  3   before insert on my_tab
  4   for each row
  5   begin
  6    /* Let's lock sequence in exclusive mode */
  7    update numer_tab set id = id + 1
  8    returning id into :new.id;
  9   end;
10  /
&nbsp
Trigger created.Now I havn't to worry about gaps:
Fisrt session:
SQL> insert into my_tab values(null);
&nbsp
1 row created.because my next session is waiting:
SQL> insert into my_tab values(null);
&nbspI do commit in first and second session -everything is OK:
SQL> commit;
&nbsp
Commit complete.
&nbsp
SQL> select * from my_tab;
&nbsp
        ID
         2
         1Now I do the same but do rollback in 1th:
SQL> insert into my_tab values(null);
&nbsp
1 row created.
&nbsp
SQL> rollback;
&nbsp
Rollback complete.and commit in 2th:
SQL> insert into my_tab values(null);
&nbsp
1 row created.
&nbsp
SQL> commit;
&nbsp
Commit complete.No gaps:
SQL> select * from my_tab;
&nbsp
        ID
         2
         3
         1Now I will not lock sequence resource due a transaction:
SQL>  create or replace trigger
  2   tr_no_gap
  3   before insert on my_tab
  4   for each row
  5   declare
  6    pragma autonomous_transaction;
  7   begin
  8    /* Let's lock sequence in exclusive mode */
  9    update numer_tab set id = id + 1
10    returning id into :new.id;
11    commit;
12   end;
13  /
&nbsp
Trigger created.And I repeate my last operation.
Both inserts execute immediately
1th
SQL> insert into my_tab values(null);
&nbsp
1 row created.2th
SQL> insert into my_tab values(null);
&nbsp
1 row created.Now I rollback the first and commit the second.
And what I see is the gap:
SQL> select * from my_tab;
&nbsp
        ID
         2
         3
         5
         1We are just trying to explain what you will have to
pay the serious price of performance in the
absence of gaps and you will have the lack
of Oracle multithreading advantage in this case.
I doubt your customers will happy with that.
Rgds.