2.1-1 Primary keys
---------------------------------------------
Markus Winand는 SQL에 대한 통찰력을 제공하고 다양한 시스템이 SQL을 지원하는 방법을 modern-sql.com 에서 보여줍니다. 이전에 그는 use-the-index-luke.com 을 만들었는데, 지금도 활발하게 유지되고 있습니다. Markus는 winand.at 를 통해 강사, 연사 및 컨설턴트로 고용될 수 있습니다.
---------------------------------------------
You can upload a Korean translation of use-the-index-luke.com on your blog
Thank you from the bottom of my heart to author Makus Winand for allowing me.
These are translations that I use for studying by using a papago (google translate)
The translations may not be correct or there may be a typo.
I'd appreciate it if you could point it out in the comments.
---------------------------------------------
---------------------------------------------
use-the-index-luke.com 의 한글번역본을 블로그에 업로드 해도 된다고
허락해주신 Makus Winand 님께 진심으로 감사합니다.
이 번역본들은 제가 공부용도로 번역기(papago, google transrate)를 돌려서
번역한 내용들이라 맞지 않거나, 오타가 있을수 있습니다.
댓글로 지적해주시면 감사하겠습니다.
---------------------------------------------
https://use-the-index-luke.com/sql/where-clause/the-equals-operator/primary-keys
우리는 가장 간단하지만 일반적인 where 절인 기본 키 조회로 시작하겠습니다.
이 장의 전체 예제에서는 다음과 같이 정의된 EMPLOYEES 테이블을 사용합니다.
--------------------------------------------
CREATE TABLE employees (
employee_id NUMBER NOT NULL,
first_name VARCHAR2(1000) NOT NULL,
last_name VARCHAR2(1000) NOT NULL,
date_of_birth DATE NOT NULL,
phone_number VARCHAR2(1000) NOT NULL,
CONSTRAINT employees_pk PRIMARY KEY (employee_id)
)
--------------------------------------------
데이터베이스는 자동으로 기본키에 대한 인덱스를 생성합니다.
그 의미는 EXPLOYEE_ID 컬럼에 create index문을 실행하지 않아도 인덱스가 존재한다는 뜻입니다.
--------------------------------------------
Tip
EMPLOYEES table 은 샘플 데이터 입니다.
사용자 환경에서 테스트하는데 사용할 수 있습니다.
이 지시사항을 따라가면 테이블에 1000rows가 포함됨을 알 수 있습니다.
--------------------------------------------
다음 쿼리는 기본키를 검색하여 employee's name을 검색합니다
--------------------------------------------
SELECT first_name, last_name
FROM employees
WHERE employee_id = 123
--------------------------------------------
기본 키 제약 조건은 ID 값의 고유성을 보장하므로 where 절은 여러 행과 일치할 수 없습니다.
데이터베이스는 인덱스 리프 노드를 따를 필요가 없으므로 인덱스 트리를 통과하기에 충분합니다.
우리는 실행계획을 통해 검증 할 수 있습니다.
--------------------------------------------
EXPLAIN plan FOR
SELECT first_name, last_name
FROM scott.employees
WHERE employee_id = 123;
SELECT *
FROM TABLE(dbms_xplan.display);
Plan hash value: 3640292141
--------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 1017 | 1 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| EMPLOYEES | 1 | 1017 | 1 (0)| 00:00:01 |
|* 2 | INDEX UNIQUE SCAN | EMPLOYEES_PK | 1 | | 1 (0)| 00:00:01 |
--------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("EMPLOYEE_ID"=123)
--------------------------------------------
오라클 실행 계획에는INDEX 순회만 실행하는 INDEX UNIQUE SCAN이 표시됩니다.
인덱스의 로그 확장성을 최대한 활용하여 거의 테이블의 크기와 상관없이 매우 빠르게 항목을 찾습니다.
--------------------------------------------
실행 계획은 데이터베이스가 SQL문을 실행하기 위해 수행하는 단계를 보여줍니다. 부록 A 에서는 다른 데이터베이스를 사용하여 실행 계획을 검색하고 읽는 방법을 설명합니다.
--------------------------------------------
인덱스에 액세스한 후 데이터베이스가 쿼리된 테이블 데이터(FIRST_NAME, LAST_NAME) 를 가져오려면 한 단계 더 수행해야 합니다.
바로 인덱스 ROWID를 이용한 TABLE 접근작업 입니다.
(TABLE ACCESS BY INDEX ROWID opertaion)
이 작업은 "Slow Indexes, Part 1"에서 설명하였듯 성능 병목 현상이 발생할 수 있지만, INDEX UNIQUE SCAN에서는 이러한 리스크는 발견되지 않습니다.
이 작업은 두개 이상의 row를 제공하지않고,
두번이상의 테이블 접근(access)이 일어나지 않습니다. 이는 느린 쿼리의 요소가 INDEX UNIQUE SCAN에는 함께하지 않다는 것을 의미합니다.
--------------------------------------------
Unique Index가 없는 기본키
기본키에는 고유한 인덱스가 필요하지 않으며 고유하지 않은 인덱스도 사용할 수 있습니다. 이 경우 Oracle DATABASE는 INDEX UNIQUE SCAN을 사용하지 않고 INDEX RANGE SCAN작업을 사용합니다.
그럼에도 불구하고, 제약 조건은 여전히 키의 고유성을 유지하여 인덱스 조회가 최대 하나의 항목을 제공합니다.
기본 키에 고유하지 않은 인덱스를 사용하는 이유 중 하나는 지연된 제약조건 (deferrable constraints) 입니다. sql문 실행 중에 검증되는 일반 제약 조건과 달리 데이터베이스는 트랜잭션이 커밋될때까지 deferrable constraints의 유효성검사를 연기합니다.
의존성 순환(circular dependencies)이 있는 테이블에 데이터를 삽입하려면 지연된 제약조건이 필요합니다.
--------------------------------------------
--------------------------------------------
https://brunch.co.kr/@fishz/143
ㄴ circular dependencies(상호 참조/의존성 순환)
A 모듈이 B 모듈을 참조하고 있고 동시에 B모듈도 A모듈을 참조하고 있는 경우이다.
https://neo-orcl.tistory.com/entry/constraints-deferred
ㄴ Contsraints deferred(지연된 제약조건)
: 기본적으로 제약조건이 걸린 컬럼 에대한 DML 수행시 한건씩 제약조건을 검사하여 제약조건 위반시 statement level rollback이 되는데,
제약조건에 deferred를 설정하면 이를 한건씩이 아닌 commit 시에 트랜잭션 단위로 제약조건을 검사하고 제약조건위반시 자동으로 트랜잭션을 rollback 하는 기능
--------------------------------------------