1) 이전에는 어떤 문제가 있었나요?
지난 주차에는 **인 메모리(In-Memory)** 방식으로 데이터를 저장하거나, NoSQL 데이터베이스인 MongoDB를 사용하여 “**해야할 일**” 데이터를 저장하였습니다.
하지만 이런 저장 방식은 정형화된 데이터를 관리하거나 복잡한 비즈니스 로직을 구현하기에는 적합하지 않습니다.
예를 들어, 여러분들이 MongoDB에서 여러 컬렉션을 합쳐 조회하려고 할 때, 특정 **필드(Field)**가 존재하지 않는다면, 문제가 발생할 수 있습니다.
→ “**해야할 일**” 데이터에서 “**할 일 완료(`doneAt`)**” 필드 같은 경우, 해당 작업이 완료되지 않으면 필드 자체가 존재하지 않는 것 처럼 말이죠. 😉
이와 같은 문제점을 해결하기 위해 데이터의 **정규화**와 **무결성**을 보장하면서 **정형화**된 데이터를 효과적으로 관리할 수 있는 **관계형 데이터베이스(RDB, Relational DataBase)**가 탄생하게 된 것입니다. 🙂
2) 관계형 데이터베이스(RDB, Relational DataBase)
📌 관계형 데이터베이스(RDB, Relational DataBase)는 각 데이터를 ‘테이블’이라는 표형태의 구조에 저장합니다. 여기서, 각 ‘테이블’은 여러 정보를 저장하며, ‘테이블’간에 연관 관계를 설정하여, 여러 테이블에 분산된 데이터를 서로 연결하여 관리할 수 있습니다.
그렇다면, 이 두 데이터베이스는 어떻게 다를까요?
데이터 형식이 자유로웠던 비관계형 데이터베이스와 달리 관계형 데이터베이스는 "테이블" 이라는 개념이 존재합니다. 여기서 테이블이란, 여러개의 ‘열(column)’과 ‘행(row)’을 가지는데, 이는 저희가 많이 사용한 엑셀의 표와 유사한 형태입니다.
각 행(row)은 고유한 데이터(record)를 나타닙니다. 예를 들어 ‘테스트닉네임’이라는 사용자의 정보가 될 수 있어요. 반면에, 각 열(column)은 해당 데이터의 속성(field)을 표현하고, ‘이메일’, ‘닉네임’, ‘비밀번호’와 같이 사용자의 구성 요소를 뜻 하는것이죠.
한 가지 주목해야 할 점은 이 테이블(표)들 간에는 서로 연관 관계(Relationship)를 가질 수 있다는 것입니다. 이러한 관계를 통해 더욱 복잡한 쿼리를 작성할 수 있고, 바로 이 점이 “관계형 데이터베이스”라는 이름의 유래가 된것이죠.😉
하지만 비관계형 데이터베이스(NoSQL)가 나쁘다는 것은 아닙니다. 유연한 데이터 구조를 가지기 때문에, 저장(Write)과 읽기(Read) 작업이 더욱 빠르며, 복잡한 비즈니스 로직 없이 주로 데이터 읽기와 쓰기에 중점을 둔 서버에서 주로 사용한답니다.
→ 빅데이터 환경이나 단순 페이지뷰가 많은 어플리케이션에서 주로 사용 되겠죠?
반면, 관계형 데이터베이스(RDB)는 더욱 복잡한 비즈니스 로직과 정형화된 데이터를 체계적으로 관리할 수 있어 더욱 안전한 서버 환경을 구성하기에 좋습니다.
→ 특히 보안이 중요한 기관이나, 은행과 같은 안전성을 중시하는 회사들에서 주로 볼 수 있겠죠?
💪 이렇듯 각 데이터베이스들은 특별한 장단점을 가지고 있습니다. 결국 어떤 기술 스택을 선택할지는 해당 프로젝트의 요구사항에 따라 달라지게 되는 것 이죠. 😎
4) MySQL 이란?