- SELECT 구문에는 데이터를 “어떤 방법으로” 선택할지 일절 쓰여 있지 않다는 것입니다. 이 방법(=절차 지향)은 DBMS에게 맡기게 됩니다. “최대한 쉽게 만드는 것” 이 RDB의 기본 정신입니다. 사용자가 생각해야 하는 것은 어떤 데이터가 필요한지 정도입니다. 이외의 것은 모두 DBMS라는 하인에게 맡기면 된답니다.
- WHERE은 어디? 를 나타내는 의문사가 아니라, “~라는 경우” 를 나타내는 관계부사입니다.
- SELECT 구문의 입력과 출력 자료형은 “테이블(관계)” 입니다. (중략) 이외에는 어떠한 자료형도 존재하지 않습니다. 이러한 성질 때문에 관계가 닫혀있다는 의미로 폐쇄성(Closure Property) 이라고 부릅니다.
- GROUP BY 구의 기능을 쉽게 표현하면 “테이블을 홀 케이크처럼 다룬다” 라고 할 수 있습니다.
- (더 좋은 예시가 없었을까? 이걸 처음 접하는 사람한테는 더 쉬운 예시가 필요할 수 있어 보인다. 청팀, 백팀 나누기? 반별로 줄세우기? )
- 뷰라는 것은 “테이블의 모습을 한 SELECT 구문”
- SQL의 성능은 저장소 I/O를 얼마나 감소시킬수 있을지가 열쇠
- UNION에서 조건 분기를 표현한다면 “내가 지금 쓸데없이 길게 쓰고 있는 것은 아닐까?” 라는 것을 항상 의식할 것
- IN 또는 CASE 식으로 조건 분기를 표현할 수 있다면, 테이블에서의 스캔을 크게 감소시킬 가능성이 있음
- UNION, OR, IN 을 활용한 각각의 쿼리 성능을 비교한 섹션
- (IN 으로 했을 때, 괜찮아지는 경우도 있었던 것 같은데 책에서는 그게 아닌 것으로 나옴. 직접 벤치마킹을 한번 해봐야할 것 같음)
노트
총 8개 · 1 / 1 페이지
이제 캡스톤프로젝트 발표가 끝나고, 보고서 작업만 남았다. 이번 프로젝트를 통해 여러 기술들을 써볼 수 있었고, 팀원들과도 좋은 협업을 할 수 있어서 즐거운 경험을 한 것 같아 뿌듯하다. 그와 동시에 학교 졸업이 얼마 남지 않았다는 것에 막연한 불안감도 있다. 앞으로 어떤 직장을 다니게 될지, 어떤 일을 하게 될지 아직은 해매고 있는 것 같다. 그래도 이번 프로젝트를 통해 배운 것들을 바탕으로 앞으로도 계속 성장해 나갈 수 있을 것 같다는 생각을 가져본다.
9년만에 해외여행으로 일본에 다녀왔다. 오랜 기간동안 달려온 나에게는 휴식을 주는 좋은 기회였고, 충전된 상태로 다시 일상으로 돌아올 수 있게 된 계기였다.
840 여일의 연속 스트릭이 있었던 백준 온라인 저지가 서비스 종료가 되고 나서, 개인적으로 많은 아쉬움이 있었다. 그렇게 10년 정도의 알고리즘과 함께한 기간을 되돌아보는 계기가 되었다. 코딩테스트와 관련된 알고리즘 공부는 AI 시대가 되고 나서 의미가 없어진 것 같다. 하지만 개발자로 이끈 알고리즘과 프로그래밍 그 자체의 행위에 대해 행복함을 느끼는 난 뭐라도 해야할 것 같다는 생각으로 돌아왔다. 그래서 Leetcode로 옮겨서라도 풀어보려 한다. 이게 큰 도움이 안 될거라는 건 알지만, 뭔가 계속 한다는 그 자체가 좋은 것 같다.
별도로 애니메이션 기능을 위해 스튜디오도 만들어두고 이를 json으로 관리하게 해봤다. 조금씩 개선해보면서 설명글에 애니메이션도 넣어서 더 좋은 퀄리티의 글을 쉽게 뽑아내는 과정을 만들어보고 싶었다.
프로젝트 기능, 레퍼런스를 관리하기 위한 기능, latex 지원 등 기능들을 추가해봤다. opencode로 구성된 개발환경은 이를 너무 쉽게 할 수 있게 되었다. 내가 자고 있는 동안, 기능은 완성되어있었다.
별도 에디터를 추가하여 작성하는 방식과, 코드 블럭이나 다이어그램에 대한 기능을 더 추가해봤다.
새로운 블로그를 구성해보려고 한다. 좀더 동적인 컨텐츠를 넣기도 하고, 개인적인 생각이나 일상적인 이야기도 담아보고자 한다.