노트

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

840 여일의 연속 스트릭이 있었던 백준 온라인 저지가 서비스 종료가 되고 나서, 개인적으로 많은 아쉬움이 있었다. 그렇게 10년 정도의 알고리즘과 함께한 기간을 되돌아보는 계기가 되었다. 코딩테스트와 관련된 알고리즘 공부는 AI 시대가 되고 나서 의미가 없어진 것 같다. 하지만 개발자로 이끈 알고리즘과 프로그래밍 그 자체의 행위에 대해 행복함을 느끼는 난 뭐라도 해야할 것 같다는 생각으로 돌아왔다. 그래서 Leetcode로 옮겨서라도 풀어보려 한다. 이게 큰 도움이 안 될거라는 건 알지만, 뭔가 계속 한다는 그 자체가 좋은 것 같다.

새로운 블로그를 구성해보려고 한다. 좀더 동적인 컨텐츠를 넣기도 하고, 개인적인 생각이나 일상적인 이야기도 담아보고자 한다.