Implement Conditional Read-Only of Column Across Two Tables

Question

Hello,
I would like to implement a "conditional read-only" mechanism on a column in a table with two tables in total being involved in this situation.
I have a demo/proof of concept of this and things are working as expected in the tests I have performed; however, I would like any input as to whether there is a better way, etc.
Here's a contrived demo but which illustrates the key ingredients nevertheless. Oracle version 10.2.0.4 64-bit on Windows Server 2008 Release 2 64-bit.
- Table DDL and small sample data
create table band(
  band_id   number primary key,
  band_name varchar2(20),
  status    varchar2(20)
create table band_member(
  band_id references band,
  member_name varchar2(20)
insert into band values(3, 'The Rutles', 'prefab4');
insert into band values(4, 'The Beatles', 'established');
commit;
insert into band_member values(3, 'Ron Nasty');
insert into band_member values(3, 'Dirk McQuickly');
insert into band_member values(3, 'Stig O''Hara');
insert into band_member values(3, 'Barrington Womble');
commit;
insert into band_member values(4, 'John Lennon');
insert into band_member values(4, 'Paul McCartney');
insert into band_member values(4, 'George Harrison');
insert into band_member values(4, 'Ringo Starr');
commit;- The rules regarding the conditional read-only goal
1. Not permitted to update band.band_name when band.status='prefab4'
2. Not permitted to insert/update/delete any rows in band_member when the parent row has band.status='prefab4'
- Triggers used to implement the goal (current solution)
create or replace trigger t1
before update of band_name on band
for each row
when (old.status = 'prefab4' or new.status = 'prefab4')
begin
  raise_application_error(-20010,
    'can not update band_name when status=''prefab4''');
end;
create or replace trigger t2
before insert or update or delete on band_member
for each row
declare
  l_status band.status%type;
  l_band_id band_member.band_id%type;
  cursor l_cursor (p_band_id number) is
  select status from band
  where band_id = p_band_id
  for update;
begin
  if updating or inserting then
    l_band_id := :new.band_id;
  else
    l_band_id := :old.band_id;
  end if;
  open l_cursor(l_band_id);
  fetch l_cursor into l_status;
  close l_cursor;
  if l_status = 'prefab4' then
    raise_application_error(-20011,
      'can not update child when parent status=''prefab4''');
  end if;
end;
/- Quick sample test for each condition
update band
set    band_name = 'THE RUTLES'
where  band_id = 3;
update band
ERROR at line 1:
ORA-20010: can not update band_name when status='prefab4'
ORA-06512: at "DEMO.T1", line 2
ORA-04088: error during execution of trigger 'DEMO.T1'
update band_member
set    member_name = 'RON NASTY'
where  member_name = 'Ron Nasty';
update band_member
ERROR at line 1:
ORA-20011: can not update child when parent status='prefab4'
ORA-06512: at "DEMO.T2", line 18
ORA-04088: error during execution of trigger 'DEMO.T2'As I say, whilst my simple tests look to show the correct results, I'm left wondering if there might be a better way to implement said functionality.
I've attempted to provide the required information, but if I've managed to omit anything, please let me know.
Cheers,
Chalfont

Answer 1

Hi, Chalfont,
user13146957 wrote:
I went the cursor route to add the "for update" clause to force serialisation on the row - i.e. the idea was to avoid the case where another session might have wanted to update the status an instant after my fetch but before the remainder of the code completed. Does that make sense?No not really. The trigger on band prevents anyone from ever changing status from 'prefab4' to anything else (or vice-versa).
Even aside from that, you're putting in some effor to prevent something that will be allowed a split second later (or maybe the other way around). What's so significant about that split second?
I've been thinking of other ideas rather than the trigger approach, but have come up empty, as it were, thus far. I'm open to using other approaches and making some schema changes is not off the table either.FGA (Fine Grained Access), or its older sibling VPD (Virtual Private Database) can also do what you want, but, instead of raising an error, they just ignore the illegal action. This may be an advantage or a disadvantage, depending on your requirements.
Another approach is for the owner of the table not to grant INSERT, UPDATE or DELETE privileges to anyone: all DML must be done through a procedure (or procedures) owned by the table owner, who grants EXECUTE privileges instead of the other privileges.