B.E.S.T.DB




왼쪽은 ARC-Relationship도 나오고 Entity 도 여러개가 나와 있는데 오른쪽은 Arc도 사라지고 Recursive Relationship 으로 표현되어 있다.

ARC-Relationship ( 상호배타적 독점관계 )
예) 개인, 법인 서로 다른 Entity 그리고 계좌
     계좌의 주인은 둘중의 하나다. 개인일수도 있고, 법인일수도 있다.
     이런걸 표현할때 상호배타적 독점관계라고 한다.

가장 좋은 모델링은 오른쪽 처럼 단순 명료한 설계!


커뮤니티 DB에서 동호회별로 테이블을 쪼갠다면? 포퍼먼스가 좋아질까?

답) 아니다.
한개의 테이블에 전체 동호회정보를 가지고 있는것보다 동호회별로 테이블을 조개는게 성능이 좋을것 같지만 동호회중에서 데이터량이 많은 동호회가 있을것이다.
그 동호회에서 데이터를 검색을 하면 부하는 크다.
사용량이 적어서 데이터량이 적은 동호회의 테이블은 부하가 적을지만
사용량이 많아서 데이터량이 많은 동호회의 테이블의 부하하는 크다.

테이블을 쪼개는것보다 인덱스 전략으로 해결하는것이 좋다.


디비의 성능을 좌우하는것중 가장 중요한것은 I/O, 그리고 DBMS Call 을 최대한 줄이는것이다.

예)
10만건의 데이터를 UPDATE 해야한다.
이걸 UPDATE 문 한번에 처리하는것이 좋을까? 아니면 LOOP를 돌려서 10만번 돌려서 처리하는것이 좋을까?
답은 UPDATE 문 한번에 처리!


SQL문을 실행했을때 처리 순서

1) SELECT 어쩌구 저쩌구 SQL문 실행

2) SQL문을 해석해서 Data Dicionary 에서 컬럼명, 테이블이름, 컬럼 데이터타잎이 맞는지 확인해서 SQL문을 수행할때 문제가 없는지 확인

3) 실행계획 수립
   클러스터 인덱스가 있는지 넌클러스터 인덱스가 있는지 그것을 사용할 수 있는지 확인하고 최적의 SQL문을 찾아낸다.

4) 실행

2,3,4 단계는 OPTIMIZER 에서 수행한다.
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

Comment +0

티스토리 툴바