SQL 개발 사양

현재 보험 프로젝트의 SQL 개발 규범.
>>SQL 개발의 일반 프로세스<<
표 구조->인덱스->역사 데이터->목표->SQL 쓰기 사고방식->개발->디버깅
프로그램 개발을 진행하기 전에 바로 인코딩을 서두르지 말고 표 구조를 먼저 연구해야 한다. 특히 표 안의 역사 데이터와 표 안의 데이터의 작성 방식을 연구하려면 시작하기 전에 반드시 표의 인덱스를 미리 연구해야 한다. 만약에 인덱스가 부족하면 먼저 인덱스를 추가하고 개발해야 개발 프로그램의 오류율과 운행 성능 문제를 줄이고 적응성을 높일 수 있다.
>> 일반적인 데이터베이스 도구 및 사용 제한 기술<<
데이터베이스 관련 도구:
SQL을 작성해야 하는 개발자에게 편리하고 도형화된 클라이언트 소프트웨어를 제공하여 SQL을 실행하고 테이블 구조, 인덱스 등, 예를 들어 TOAD, PL/SQL Develop 소프트웨어를 볼 수 있다.
사용 제한:
여기서 말한 제한 사용은 다른 기술 경로가 있다면 다음과 같은 Oracle 기술을 사용하지 말라는 뜻이다. DBLink, Trigger, 자바로 작성된 저장 프로세스 등 내용을 포함한다.
>> 사용할 수 없는 SQL 문장<<
1. 표 안에 기록된 수량이 얼마든지 상관없이 물리 데이터베이스 관련 조회를 엄격히 금지한다.
예를 들어 통계 시스템 업무 직원 번호와 그에 대응하는 통계 기구 코드를 조사한다.

	select a.empno, b.deptno 
		from remotedb@onhdrb:empno a , statistics@onhdrb:tjywbm b 
		where a.deptno=b.ywbm;

2. 3개 표(3개 표 포함) 이상의 관련 조회를 엄격히 금지한다. 표 안에 기록된 수량이 얼마든지 상관없다.

select  	processtype, ds_process.ds_process_id, ds_process.createperson,
            ds_process.startdatetime, dsb_apply.dsb_apply_id, ds_activity.executeorg,
    	ds_activity.step
from ds_activity, ds_process, dsb_apply 
where   	ds_process.ds_process_id=dsb_apply.ds_process_id and
    	ds_process.processtype=3 and ds_process.nextactivitytype=2 and
    	ds_process.createperson=3394 and
    	ds_activity.ds_activity_id=ds_process.ds_activity_id order by
    	dsb_apply.dsb_apply_id desc

상기 문구는 엄격하게 금지되어 있으며 한 표가 100만 기록을 초과하면 보통 10분 안에 조회할 가능성이 크지 않다.성능은 표 사이의 쓰기 순서와 매우 큰 관계가 있다.
3. 두 표 모두 5000개 이상의 기록을 초과한 두 표의 관련 조회를 엄격히 금지한다.
두 표 모두 5000개 이상의 기록을 초과한 관련 표 조회는 <<관련 SQL 문장 작성 심사 비준표>>>를 작성하고 심사 동의를 받아야 심사 비준 동의에 따라 문장을 사용할 수 있다(관련 필드도 인덱스에 기초해야 한다).
성능 분석에 따르면 테이블 조인 순서를 잘 선택하는 것이 중요합니다.
WHERE 자문에 여러 개의 표가 연결되어 있을 때, WHERE 자문에서 마지막 표는 줄 수가 가장 적을 수 있는 표이고, 필터 조건이 있는 자문은 WHERE 자문에서 마지막에 놓아야 한다.
4. 트랜잭션 제출에 대한 처리 방법
제출 사무는 원칙적으로 백엔드 프로그램에서 진행해야 하며 C/S 구조, B/S 구조류 시스템이 백엔드 처리 프로그램에서 이산적, 대기적 사무를 제출하는 것을 엄격히 금지해야 한다.긴 업무는 데이터베이스 잠금을 초래하기 쉬우므로 업무 시작과 업무 끝 사이에 집중적으로 작성하고 한꺼번에 제출해야 하며 select 문구가 존재하는 것을 금지해야 한다.(단 개발 도구 자체의 데이터베이스 조작을 일으키지 않는 함수와 문장도 있고 PB 자체의 자동 제출 기능도 있다).
>> 권장되지 않는 SQL 문장<<
1. 다중 사용자 동시 선점에 대한 유일한 흐름 번호를 처리하는 다중 사용자 동시 선점 메커니즘은'공유-선점-재시도'방식으로 진행하는 것을 권장하고'선점-잠금-잠금해제'방식으로 진행하는 것을 권장하지 않는다.
2. 통계 프로그램 추출문과 밀어넣기문에 대한 처리.
원칙적으로 원본표에'데이터를 추출하는 방식을 사용하는 것을 권장하지 않고, 원본표를 한 번 스캔하여 여러 목적표에'데이터를 작성하는 방식으로 통계, 분류 프로그램을 개발하여 운영 효율을 효과적으로 높여야 한다.
3. 대량의 정렬 조작은 시스템 성능에 영향을 미치기 때문에order by,group by,distinct 등 정렬 조작을 최대한 줄인다.정렬 작업을 사용해야 한다면, 정렬은 색인이 있는 열에 세워야 합니다.관련 조회의 다중 필드 정렬을 사용하는 것을 권장하지 않습니다.
4.SELECT*:SELECT 문장에 선택할 모든 열 이름을 써서 문장의 가독성을 강화하고 불필요한 선택을 피하는 것을 권장하지 않습니다.SELECT*는 모든 필드에 대한 의존도를 증가시켰습니다. 표에 필드를 추가하면 오류가 발생할 수 있습니다.또한 데이터의 흐름을 증가시키고 실제 필요하지 않은 필드를 조회할 수 있다.
5. SQL 문에는 문자열에서 대문자로 입력해야 하는 내용을 제외하고 키워드를 포함한 모든 소문자가 있습니다. 대소문자 결합은 대문자 입력 속도가 느리기 때문입니다.(같은 SQL 문장은 SQL 버퍼에서 읽히고 SQL 분석기는 SQL 문장을 재분석하여 실행 계획을 세우지 않아 시스템 응답 시간이 크게 줄어든다).
>> 인덱스 사용<<
1. 스텔스 변환으로 인덱스가 효력을 상실합니다.이 점은 마땅히 중시를 불러일으켜야 한다.개발 중에 자주 범하는 실수이기도 하죠.
테이블의 필드 때문에tumdn은varchar2(20)로 정의되었지만, 검색할 때 이 필드를number 형식으로where 조건으로 Oracle에 전송하면 색인이 효력을 상실할 수 있습니다.
잘못된 예: select * from test where tumdn=13333333333;
올바른 예: select * from test where tumdn='13333333333';
   2. 색인열을 연산하면 색인이 효력을 상실합니다. 제가 가리키는 색인열을 연산하면 (+,-,*,/,!)
잘못된 예: select * from test where id-1=9;
올바른 예: select * from test where id = 10;
   3. Oracle 내부 함수를 사용하여 인덱스가 잘못되었습니다.이러한 경우 함수 기반 인덱스를 만들어야 합니다.
잘못된 예: select * from test where round (id) = 10;이 때 id의 인덱스가 작동하지 않는다는 것을 설명합니다
올바른 예: 먼저 함수 인덱스를 만들고create index testid_fbi_idx on test(round(id));그리고 select * from test where round (id) = 10;이때 함수 인덱스가 작용했다
   4. 아래의 사용은 색인을 실효시킬 수 있으므로 사용을 피해야 한다.
a. <>, not in, not exist,!= 사용
b. like "%_"백분율은 앞에 있습니다. (색인을 만들 때 Reverse (column Name) 로 처리할 수 있습니다.)
c. 복합 인덱스에서 첫 번째 위치가 아닌 인덱스 열을 단독으로 인용한다.항상 색인의 첫 번째 열을 사용해야 합니다. 만약 색인이 여러 열에 세워져 있다면, 첫 번째 열이where 자문에서 인용될 때만 최적화기가 이 색인을 사용할 수 있습니다.
d. 문자형 필드가 숫자일 때where 조건에 인용부호를 추가하지 않습니다.
e. 변수가times 변수를 사용하고 표의 필드가date 변수를 사용할 때.혹은 상반된 상황.
    5. 빈 변수 값을 비교 연산자(기호)와 직접 비교하지 마십시오.
변수가 비어 있을 수 있으면 IS NULL 또는 IS NOT NULL을 사용하거나 ISNULL 함수를 사용해야 합니다.
    6. SQL 코드에 큰따옴표를 사용하지 마십시오.
문자 상수는 작은 따옴표를 사용하기 때문이다.객체 이름을 제한할 필요가 없는 경우 (비ANSI SQL 표준) 괄호를 사용하여 이름을 괄호로 묶을 수 있습니다.
    7. 색인이 있는 테이블 공간과 데이터가 있는 테이블 공간을 각각 다른 디스크chunk에 설치하면 색인 조회의 효율을 향상시키는 데 도움이 된다.
    8. Oracle에서 기본적으로 사용하는 대가 기반 SQL 최적화기(CBO)는 통계 정보에 매우 의존하기 때문에 통계 정보가 정상적이지 않으면 데이터베이스 조회 시 색인을 사용하지 않거나 잘못된 색인을 사용할 수 있다.
일반적으로 Oracle의 자동 작업에는 통계 정보를 업데이트하는 문구가 포함되어 있지만 테이블 데이터에 비교적 큰 변화(20%를 초과)가 발생하면 통계 정보를 즉시 수동으로 업데이트하는 것을 고려할 수 있다. 예를 들어analyze table abc 컴퓨터 statistics이다. 그러나 통계 정보를 업데이트하는 것은 시스템 자원을 소모하기 때문에 시스템이 한가할 때 실행하는 것을 권장한다.
    9. Oracle은 질의를 한 번 수행할 때 일반적으로 테이블에 대한 색인 하나만 사용합니다.
따라서 때때로 너무 많은 인덱스는 Oracle이 잘못된 인덱스를 사용해서 조회 효율을 떨어뜨릴 수 있습니다.예를 들어 어떤 표에 인덱스 1(Policyno)과 인덱스 2(classcode)가 있는데 검색 조건이 policyno ='xx'and classcode ='xx'인 경우 시스템은 인덱스 2를 사용할 수 있다. 인덱스 1을 사용하는 것보다 검색 효율이 현저히 떨어진다.
    10. 우선, 가능한 한 섹션 인덱스를 사용하십시오.