고양이 두 잔

목차 FastAPI와 SQLAlchemy, 그리고 Pydantic을 이용한 토이 프로젝트를 진행하던 중 PostgreSQL을 사용해야 할 일이 생겼다. 그냥 MySQL을 사용했어도 되지만, SQLAlchemy와 궁합이 좋은 디비가 PostgreSQL이라길래. 찍먹 하듯이 잠깐 사용하고 넘어가게 될 테지만, 그래도 이렇게 만난 것을 기념으로 블로그에 정리를 해두기로 했다. PostgreSQL, 시작해 보자. Brief History PostgreSQL의 독음은 '포스트그레스큐엘'이다. MySQL을 '마이 에스큐엘'이라고 부르는 것과 차이가 있는데, 포스트그레스큐엘의 개발 과정을 살펴보면 그 이유를 알 수 있다. 포스트그레스큐엘은 캘리포니아대학 버클리분교의 Ingres 프로젝트에서 시작되었다. 이후 문제점을..

가장 최근에 과제 전형을 경험한 회사에서 MySQL이 아닌 MariaDB를 기본으로 한다는 말을 들었다. MariaDB에 대해 전혀 모르고, 아는 거라곤 '라이선스 문제로 갈라져 나온 MySQL의 갈래 아닌가..?' 정도여서 이참에 개념을 확실히 잡고, MySQL로 진행한 과제전형을 MariaDB로 바꿔보려고 한다. 우선 디비에 대한 소개부터. MariaDB MariaDB는 오라클로 넘어간 MySQL의 라이선스 상태에 반발해 2009년에 최초 출시된, 오픈소스 RDBMS이다. MySQL을 포크 해서 개발한 DB 답게 로고도 역시 해양생물인 바다사자이며, 이름은 개발자 몬티 와이드니어스의 둘째 딸 마리아에서 따왔다고 한다. MySQL과의 높은 호환성을 위해 저작권 공유 정책을 시행하고 있으며, 그 목표는 ..

목차 안 그래도 VSCode의 불편함(?)과 스크립트 언어에 적응하느라 정신이 없는데 새로 배워야 할 단어가 산더미다. 그 와중에 오늘 클론코딩을 하다가 Form과 ModelForm은 다르다는 충격적인 사실을 알게 되었는데, 알아보니 조금 다른 것이 아니라 많이 다른 것 같아서, 꼭 정리해야 할 것 같아서 글쓰기 창을 열었다. 여기서는 일단 구분만 하고 한동안 적응한 후 다음 글을 써도 쓰기로 하고, 최대한 짧고 간결하게 정리해 보자. 들어가기 전에, Form과 ModelForm은 둘 다 장고에서 제공하는 클래스이다. Form Form 클래스는 일반적으로 API를 통해 들어온 입력의 유효성을 검증하는 데 사용된다. 따라서 HTML 렌더링과는 상관없는 것이 보통이며 따라서 모델과도 직접적인 연관관계를 갖지..

목차 지난 글에는 DB 인덱싱에 대한 소개와 그때 사용하는 자료구조인 B-Tree에 대해 적었다. 2023.03.20 - [Development/Database] - [Database]Index에 대하여 + B-Tree [Database]Index에 대하여 + B-Tree Index 인덱스란 말 그대로 색인이다. 여기선 주어진 데이터베이스에서 원하는 자료를 빨리 찾을 수 있도록 도와주는 일종의 자료구조라 할 수 있다. 원하는 테이블의 컬럼(둘 이상도 가능하다)에 gnidinger.tistory.com 요약하자면 인덱싱이란 원하는 데이터를 빨리 찾을 수 있도록 테이블 외부에 별도의 색인을 생성하는 작업이며 B-Tree란 이를 저장하기 위해 사용되는, 이진트리의 확장버전이라 할 수 있다. 추가로 B-Tree..

목차 Index 인덱스란 말 그대로 색인이다. 여기선 주어진 데이터베이스에서 원하는 자료를 빨리 찾을 수 있도록 도와주는 일종의 자료구조라 할 수 있다. 원하는 테이블의 컬럼(둘 이상도 가능하다)에 인덱스를 생성한다는 말은 데이터베이스 내부에서 해당 컬럼이 저장된 주소값을 가지는 자료구조를 테이블과 논리, 물리적으로 독립된 구조로 설계하는 것을 가리킨다. 이때 생성되는 인덱스는 컬럼의 값과 물리적 주소를 키/밸류로 가지는 구조를 가지며, 이를 이용해 빠른 탐색이 가능해진다. 참고로 인덱싱을 하지 않은 테이블의 경우, 원하는 값을 얻어내기 위해 모든 테이블을 스캔하는 Table Scan을 실행하며, 이는 최악의 경우 O(n)의 시간복잡도를 가지게 된다. 더 나가기 전에 장/단점과 인덱싱을 사용하기 좋은 환..

목차 Join Join은 간단히 말하면 필요에 의한 두 개 이상의 테이블 간 결합이다. 여기서 필요란 당연하다면 당연하게도 사용자의 필요, 따라서 개발자의 필요를 가리킨다. 따라서 Join은 필요와 목표에 의한 새로운 테이블을 (임시로) 생성하며, 데이터를 손쉽게 조회할 수 있도록 도와준다. 계속해서 테이블의 결합방식에 따른 Join의 종류를 알아보자. Inner Join Inner Join은 교집합에 해당한다. 두 테이블의 공통된 요소만 가져와 테이블을 구성하기 때문이다. 우선 다이어그램을 보면 아래와 같이 생겼다. 계속해서 간단한 두 개의 테이블로 예를 들어보자. 각 테이블에서 서로 연관된 내용만 뽑아 테이블을 생성한 것을 확인할 수 있다. 계속에서 SQL 표현식을 살펴보면, 아래와 같은 두 가지 방..

지난 글에 적었듯이 레디스는 다양한 자료형을 지원한다. 해서 조금씩 공부하면서 현재 진행 중인 프로젝트의 캐싱이나 채팅방, 인증번호 저장 등을 모조리 레디스를 사용하도록 교체할 꿈을 꾸고 있는데, 바로 적용하려니 기본 연산이 잘 들어오지 않아 힘들었다. 따라서 이번 글은 레디스에서 지원하는 자료형의 연산과 기본 명령어 등을 연습하려고 한다. 먼저 스프링부트 프로젝트를 하나 생성해서 내장 레디스를 사용하기 위한 의존성을 추가한다. dependencies { implementation 'org.springframework.boot:spring-boot-starter-web' implementation 'it.ozimov:embedded-redis:0.7.2' } 나머지 의존성은 필요에 따라 추가하면 되겠다...

지난 글에서 스키마 정제와 DB 정규화에 대해 정리하다 키(Key)에 대해서도 언급했다. 한 마디로 정의하자면 키란 테이블의 식별자 기능을 할 수 있는 하나 이상의 컬럼의 집합을 말하며, 조금 구체적으로는 아래와 같이 구분할 수 있다. 슈퍼키 - 테이블의 각 행을 유일하게 식별할 수 있는 하나 이상의 컬럼의 집합이다. 유일성을 만족한다. 후보키 - 슈퍼키 중에서 최소성을 만족하는 컬럼의 집합이다. 기본키 - 후보키 중 하나로 최소성과 유일성을 만족하는 컬럼이다. 테이블 별로 오직 하나만 지정할 수 있다. 추가로 null값을 가질 수 없고, 당연히 중복된 값을 가질 수도 없다. 대체키 - 기본키로 선택되지 않은 후보키를 말한다. 기본키와 동일한 속성을 지니며 대체도 가능하다. 이중 보통 내가 만나는 아이는..

목차 DB 설계에서 시작해 제법 멀리도 왔다. 시작점이 안 보여. 어쨌거나 DB는 한 번 잘못 설계하면 그 알아채는 타이밍이 늦을수록 돈이 들어간다. 게다가 만약 그 설계가 데이터 무결성을 무너뜨리는 것을 모자라 데이터 보안까지 위협한다? 돈으로 해결되면 다행일 것이다. 반면 당연하게도 안정적이고 성능 좋은 DB를 설계한다면 여러 비용을 절약할 수 있다. DB 설계의 세 번째 단계인 논리적 설계에서 시작해 데이터 무결성과 그 제약조건을 거쳐 여기까지 왔다. 이 글에선 DB 설계 시 개발자가 기본적으로 알아야 할, 효율적인 디자인에 대해 다룬다. 그럼 여기서 먼저, DB의 효율성이란 무엇일까? 당연히 삽입/갱신/삭제/조회의 비용이 적은 것을 말한다. 그럼 이어서, DB의 효율성을 가장 많이 해치는 근본적인..

Data Integrity 데이터 무결성은 데이터의 생애주기 동안 정확성과 일관성을 보장하고 관리하는 것을 말한다. 당연하게도 DB를 설계 및 구현할 때 최우선 순위로 확보해야 할 가치이며, 반대말로 'Data Corruption'이 있다. 여기서 정확성과 일관성이란 쉽게 말하면 언제나 의도한 대로 데이터가 저장되어야 하고 추후 복구나 조회 시 처음 상태와 같아야 한다는 뜻이며, 한 마디로 줄이자면 의도치 않은 데이터의 변경을 막는 것을 말한다. 계속해서 데이터 무결성은 두 가지 계층으로 나뉘는데, 짧게 요약하면 아래와 같다. 물리적 무결성(Physical Integrity) 실제 데이터를 안전하게 저장하고 불러오는 것에 대한 무결성 디자인 결함과 휴먼 에러에서 발생할 수 있음 물리적 저장장소를 각종 예..