4.1 기본 키와 외래 키를 사용하라

외래 키와 데이터베이스 유효성을 검사해야하는 이유

• (1) 이 애플리케이션 이외에 이 데이터르 액세스할 애플리케이션은 영원히 없는가?
• (2) 클라이언트에서 얼마나 신속하게 이 처리를 수행할 수 있겠는가?
• (3) 키를 없애라고 권고하는 컨설턴트는 코드의 줄 수에 따라 월급을 받는가?

4.2 참조 무결성의 오버헤드를 테스트하라

실습5_1(실습 준비)

create table cities
as
select username city
  from all_users
 where rownum <=37;

alter table cities
  add constraint
    cities_pk primary key(city);

create table with_ri
(x char(80),
city references cities
);

create table without_ri
(x char(80),
city varchar2(30)
);

실습5_1 (참조 무결성의 이용에 따른 성능 비용 테스트)

analyze table cities compute statistics;
analyze table with_ri compute statistics;
analyze table without_ri compute statistics;
alter session set timed_statistics=true;
alter session set sql_trace=true;
alter session set events '10046 trace name context forever, level 12';

declare
   type array is table of varchar2(30) index by binary_integer;
   l_data array;
 begin
   select * BULK COLLECT into l_data from cities;
   for i in 1 .. 1000
   loop
     for j in 1 .. l_data.count
     loop
        insert into with_ri values ('x', l_data(j));
        insert into without_ri values ('x', l_data(j));
     end loop;
   end loop;
 end;
/

exit

TKPROF C:\oracle\admin\ora9\udump\ora9_ora_652.trc ora9.trc SORT =(EXECPU) EXPLAIN = sys/sys

• TKPROF 사용 부분은 오라클 클럽의 (01.대용량 데이터베이스 스터디) > (대용량 데이터베이스 솔루션 1) > (2.SQL_TRACE,3.TKPROF(trace파일출력)) 문서를 참조했습니다.

• 프로시저의 실행으로 생긴 TKPROF 보고서

• 데이터베이스에 참조 무결성을 추가하면 전체적으로 10%~15% 정도의 오버헤드가 발생한다.
• 그러나 이정도의 오버헤드는 데이터 무결성 보장과 애플리케이션의 빠른 개발을 위해 충분히 감내할만 하다.

4.3 중간 계층의 검사가 만병 통치약은 아니다

4.3.1 속도는 빠른가?

• 중간 계층에서 작성한 로더가 원시 직접 경로 적재(native direct path load)보다 빠를까?

4.3.2 융통성은 좋아지는가?

• 데이터베이스 바깥에서 제약 조건을 검사한다면 작성해야 할 코드의 양이 증가하게 된다.

4.3.3 데이터베이스는 독립적인가?

• 대상 애플리케이션이 트랜잭션 시스템일 경우 동시성 제어와 데이터 일관성에 관한 이슈가 존재할 것이다.

4.3.4 보안은 우수한가?

감사하는 데 데이터베이스를 사용할 경우의 이점

• (1)DBA의 악의적인 행위를 탐지할 수 있다.
• (2)DBA의 감사 기능 해제 행위를 감지할 수 있다.
• (3)DBA의 감사 추적 기능 마비 행위르 감지할 수 있다.