SQL로 테이블 만들기 & 데이터 타입

14 Sep 2025 in DATABASE

‘오늘은 테이블 만드는 법 & 데이터 타입을 알아볼텐데 그냥하면 재미가 없으니까 여러분들 이마트에서 일하는 개발자라고 가정하고 이마트에서 파는 상품데이터를 DB에 저장해보자. ‘

Key-Value Database

database image

너무 간단해 보여서 쓸모가 없어보이는데 맞다 쓸모가 없다. 서브용 DB로 쓰거나 그게 전부다.
그런데 Redis라는 특수한 기능을 가진 Key-Value 데이더베이스가 있다.
이 친구는 되게 많이쓴다. 데이터를 하드디스크에 저장하지 않고, RAM에 저장을 한다. 왜냐하면 RAM이 하드보다 훨씬 빠르기 때문이다. 물론 하드에 백업은 해둔다. 메인 DB를 두고 사람들이 자주 쓰는 데이터를 redis 에 추가적으로 복사를 해둔다. 그러면 데이터 요청시 메인 DB가 아닌 redis에서 꺼내서 쓰면 속도가 빠르기때문에 효율적이다.
자주쓰는 데이터 캐싱, 채팅을 위한 pub/sub, 영상 스트리밍, 로그인 기록 저장 등에 활용한다
요즘은 redis 하나로 모든걸 다 할수 있는 redis 업글버전도 있는거 같은데 아무도 안씀

많은 사람들이 관계형 데이터베이스의 이름떄문에 관계를 잘 표현한다고 생각하는데, 실은 관계라는 표현은 수학 용어중에 Relation 이라는 행렬 배울때 쓰는 용어를 그대로 따와 붙인거다.
관계형 데이터베이스는 관계를 중점으로 다루기엔 어려움이 많다.
관계를 주로 다루고 싶다? Graph Database를 사용한다.
가장 유명한게 neo4j
노드라는걸 만들고 노드 안에 데이터들을 저장할 수 있는데, 노드끼리 어떤 관계인지를 기록할 수 있다.
데이터를 입출력할때는 Graph Query Language (GQL)이라는 언어를 이용한다.
요거 쓰면 방향도 표현이 가능하다
이걸 어디에 쓰냐고? 하면 자료간의 관계, 방향같은걸 중점적으로 저장하고 싶을때 사용. 비행기 노선이나, SNS 친구관계, 코로나전염맵, 대기업 같은경우 추천서비스 이런걸 다룰때 Graph Database 를 사용한다

“저는 수포자라서 그래프 싫은데요?”
일반적인 상황에서 쓰는 DB는 관계형 DB인데 이것보다 조금 더 자유로운게 Document Database이다.
MongoDB, CouchDB, Firestore 등이 유명함
예를들면, Collection이라는 폴더를 만들면 그 안에 document라는 파일들을 만들어서 그 파일안에 JSON 형태로 데이터를 저장할 수 있게 되어있다.
관계형 DB와 다르게 어떤 데이터를 저장할 지 미리 정의해 둘 필요도 없고, 갑자기 연락처를 추가한다던지 구조가 바뀌어도 문제가 없다.
정규화따윈 하지 않는다. 그래서 데이터 입출력 문법이 훨씬 간단하다.
대부분 분산을 염두해두고 만든 데이터베이스이기 떄문에 데이터베이스를 분산시키는게 매우 쉽다.
데이터 입출력이 매우 많은 SNS, 실시간채팅, 게시판, 온라인게임 등에 자주 사용한다.
분산하면 물론 단점도 있다. DB간의 정확도가 떨어질 수 있다.

나는 관계형 DB와 같이 표 형식으로 저장하고 싶은데 좀 유연하게 쓰고싶다? Column-Family Database 쓰면 됨
카산드라, 구글의 BigTable 같은게 있다.
해당 DB들은 똑같이 테이블을 만들고, row를 여러개 만들고 자유롭게 column을 만들어서 데이터를 기입. 행마다 컬럼이 달라도 아무 문제가 없다.
데이터 입출력을 할려면 SQL이 아니라 자기들이 만든 언어를 이용해야한다.
얘네도 정규화따윈 안한다. 데이터 입출력이 매우 쉽다.
복제, 분산 잘함. 그래서 많은 입출력을 감당해야할 때 얘네를 쓰는 경우가 있다.
Document Database와 마찬가지로 분산하면 단점으로 데이터 정확도(일관성)이 떨어진다.
가끔 데이터 저장할 때 시간 기록같은걸 되게 쉽게 해주는 기능이 있어서 시계열 데이터 저장하고 분석할때 이 DB들을 쓰는 경우가 있다. Netflix에서 님 시청기록 이걸로 분석함.