- SELECT 구문에는 데이터를 **"어떤 방법으로"** 선택할지 일절 쓰여 있지 않다는 것입니다. 이 방법(=절차 지향)은 DBMS에게 맡…
· 📖 약 2분
- SELECT 구문에는 데이터를 “어떤 방법으로” 선택할지 일절 쓰여 있지 않다는 것입니다. 이 방법(=절차 지향)은 DBMS에게 맡기게 됩니다. “최대한 쉽게 만드는 것” 이 RDB의 기본 정신입니다. 사용자가 생각해야 하는 것은 어떤 데이터가 필요한지 정도입니다. 이외의 것은 모두 DBMS라는 하인에게 맡기면 된답니다.
- WHERE은 어디? 를 나타내는 의문사가 아니라, “~라는 경우” 를 나타내는 관계부사입니다.
- SELECT 구문의 입력과 출력 자료형은 “테이블(관계)” 입니다. (중략) 이외에는 어떠한 자료형도 존재하지 않습니다. 이러한 성질 때문에 관계가 닫혀있다는 의미로 폐쇄성(Closure Property) 이라고 부릅니다.
- GROUP BY 구의 기능을 쉽게 표현하면 “테이블을 홀 케이크처럼 다룬다” 라고 할 수 있습니다.
- (더 좋은 예시가 없었을까? 이걸 처음 접하는 사람한테는 더 쉬운 예시가 필요할 수 있어 보인다. 청팀, 백팀 나누기? 반별로 줄세우기? )
- 뷰라는 것은 “테이블의 모습을 한 SELECT 구문”
- SQL의 성능은 저장소 I/O를 얼마나 감소시킬수 있을지가 열쇠
- UNION에서 조건 분기를 표현한다면 “내가 지금 쓸데없이 길게 쓰고 있는 것은 아닐까?” 라는 것을 항상 의식할 것
- IN 또는 CASE 식으로 조건 분기를 표현할 수 있다면, 테이블에서의 스캔을 크게 감소시킬 가능성이 있음
- UNION, OR, IN 을 활용한 각각의 쿼리 성능을 비교한 섹션
- (IN 으로 했을 때, 괜찮아지는 경우도 있었던 것 같은데 책에서는 그게 아닌 것으로 나옴. 직접 벤치마킹을 한번 해봐야할 것 같음)
- 반복문 의존증, 문제를 작게 나누어 레코드라는 단위에 이를 때까지 자르고 그러한 레코드에 반복문을 적용해서 문제를 해결하려는 태도
- 관계 조작은 관계 전체를 모두 조작의 대상으로 삼는다. 이러한 것의 목적은 반복을 제외하는 것이다. 최종 사용자의 생선성을 생각하면 이러한 조건을 만족해야 한다. 그래야만 응용 프로그래머의 생산성에도 기여할 수 있을 것이다.
- 반복계의 단점: SQL 실행의 오버해드 / 병렬 분산이 힘들다 / 데이터베이스의 진화로 인한 혜택을 받을 수 없다. (단지 느리기만 한 것이 아니라 느린 구문을 튜닝할 수 있는 가능성도 거의 없다고 할 수 있다.)
- 망치라는 도구만을 가지고 있는 사람에게는 모든 문제가 못으로 보인다
- 절차적 계층을 은폐하는 것이 SQL의 이념입니다.
💬 댓글