만일 총 직원수가 3만명인 사원테이블(BIG_EMP)에

메니져사원번호(MGR )가 7698 인 직원이 10,000 명이고,

부서번호(DEPTNO )가 60 인 직원이 1,200 명인 상황에서 

위의 조건에 만족하는 직원의 리스트를 조회하려고 아래와 같은

쿼리를 만들려 한다면,


SELECT * FROM BIG_EMP 

WHERE MGR=‘7698’ AND DEPTNO=’60’;


개발자는 당연히 부서번호(DEPTNO)가 60 인 직원을 먼저 조회한 후에 
메니져사원번호(MGR)가 7698 인 직원인지
판단하는 로직으로 조회쿼리를 만들고 싶어 할 것이다.

물론 DEPARTMENT와 LOCATION 둘중하나의 컬럼에만 인덱스가 생성되어있다면 그 컬럼을 먼저
사용할것이므로 순서를 고민하지 않겠지만 두컬럼이 동일한 조건이라면
  • MGR='7698' AND DEPTNO='60'
  • DEPTNO='60' AND MGR='7698'
위에 두가지중에 무엇이 더 나을까 고민을 할 수도 있다.

규칙(RULE) 기반 옵티마이져라면 
  1. 가장 나중에 생성한 인덱스가 있는 컬럼부터 파싱
  2. AND 조건이면 WHERE 절에서 가까운 순서대로, OR 조건이면 맨오른쪽에서 부터 순서대로

위의 순서대로 파싱을 한다.







비용(COST) 기반 옵티마이져(대부분의 DB가 이것을 사용함)라면 고민 할 필요가 없다.
옵티마이져가 알아서 순서를 정하기 때문이다. 


즉. 대부분의 경우 컬럼의 순서에 신경쓸 필요가 없으며 구지 신경을 쓴다면 맨뒤에서 부터 WHERE 조건을 나열하면 된다.

Posted by 빨강토끼
,
벨랜튜레이즈 알고리즘

인덱스 구조
blockA + blockL + fileA
8 + 4 + 4

같은 값이면 로우아이디순으로 소팅되어있음

인덱스사용못하는 경우
  • 인덱스를 가공 하는 경우 ( 인덱스는 like, <>, in 등 다 사용할수 있음) 
    •  좌변을 가공하지마라
    • 함수기반 인덱스 가용가능
  • NOT 부정형 조건 사용
    • bitmap index에서는 가능
  • NULL, NOT NULL
  • 옵티마이져가 취사선택
    • 의도적으로 인덱스 사용못하도록 하기
인덱스 머지 방식 실행계획

최근에 만들어진것 -> SQL 파싱할때 뒤에서 부터 파싱

힌트 / suppressing / 옵티마이저




컬럼의 형변환

NLS_DATE_FORMAT = ‘DD-MM-YY’ => ‘yyyyMMdd'



nul = chr ==> num = TO_NUM(chr)

6개컬럼 이상일때
분포도가 10~15% 이내일때
분포도가 이내가 아니여도 절대량이 많으면 클러스트링
손익분기점

인덱스 머지 보다 결합인덱스를 잘 사용하자.

인덱스머지가 불리한경우 . 분포도차이가 클때
인덱스머지가 유리한경우. 분포도차이가 적을때, 부분범위처리


Posted by 빨강토끼
,

개발자의 코드

독서/독서 2014. 4. 28. 15:37



카 와이 청 지음

상동도서관에서 빌림

2014년 4월 19일 ~ 4월 26일


02.은유

코팅을 할 시간을 자주 가져라.

오래된 코드는 주석처리하지말고 버려라.

다양성을 가져라.


03. 동기

특혜는 연봉에 있지 않고 일에 있다. 먼가를 아름답게 만들 수 있는 것에 동기를 부여하라.

시작하고 싶은 곳에서 시작하라.
- 가장 흥미로운 지점부터 바로 시작하라. 맨 처음부터 굳이 써내려 가려고 하지 마라. 나중에 리팩토링을 통해 품질을 개선 할 수 있다.

코드를 작성하기 전 아침에 소프트웨어를 테스트하라, 그 때가 가장 생생할 때이다.

침실 밖에서 일하라.
- 파킨스의 법칙  
"일은 일을 완료하기 위해 주어진 가용한 시간만큼 확장되는 경향이 있다. “

론칭자체는 별로 중요하지 않지만, 론칭날짜가 있는 것은 동기부여에 막강한 효과를 가져다준다.
합리적인 선에서 가능한 한 빨리 소프트웨어를 론칭하라.


04.생산성

마음대로 할 수 있어도, 마감일을 정하라.

훌륭한소프트웨어를 개발하기 원한다면 한도를 정하고 그것을 지켜라.

일정 수립시 세부사항은 잘라내고, 주기적으로 눈에 보이는 결과를 확인 할 수 있는 큰 덩어리로 일정을 잡아라.

매일 두 가지씩 제품을 개선 하라.

To-Do List 를 정리하라.

팀에 ‘일시 활동 중단 시간’을 만들어라.

작고 자율적인 팀에서 일하라.

생산성에서 ‘우리’를 제거하라.


05. 복잡성

코딩하기 어려운 것이 사용하기 어렵다. 단순한 로직을 유지하라.

너무 빠른 리팩토링의 위험하다. 너무 앞서가서 리팩토링을 하지마라.
설계패턴은 애플리케이션이 가까운 미래에 꼭 일어날 것 같은 업무에 필요한 정도로만 구현되어야한다.

예측하라, 하지만 주의 깊에 예측하라. 단지 작은 변화이든 큰 패턴 작업이든, 리팩토링의 결정에 따른 각각의 장단점을 주지하라.


06. 고객
서비스보다는 제품에 대한 비용을 청구하자
개발시간이 두번째 구축할때가 당연히 덜들겠지만 두번째고객에게도 그제품은 동일한가치가 있다. 대신 유연성, 전문성을 더 개선한것으로 정당화할수있고 오히려 더 높은 가격을 요구할 수도 있다


Posted by 빨강토끼
,