도대체 왜? 도대체 어떻게! DB 설계와 데이터 다루기

Description

SQL이나 데이터베이스를 배우다 보면 가끔 의문이 듭니다.

• '도대체 이거 왜 배우지?'

• '데이터 구조는 기타 프로그래밍에서 배열 정도면 충분할 거 같은데.'

하지만 하나의 목적을 지닌 프로젝트나 서비스를 개발하는 팀원으로 합류하는 순간, SQL이 꼭 데이터베이스 개발자의 영역만은 아니라는 현실이 피부에 와닿곤 합니다. 리더나 팀장님들은 대다수 개발자가 SQL정도라면 다 능숙하게 사용하고 다룰 줄 안다고 생각하며 또한 SQL을 꽤 잘 사용하는 고객도 흔히 발견할 수 있으니까요. 그만큼 많은 사람들이 DB는 쉽다고 생각합니다.

그때부터 프로그램 개발자들은 SQL을 하나의 짐짝으로 여기기 시작합니다.

• 이 로직을 쿼리로 만들어야 하나, 아님 LOOP-IF문 처리를 해야 하나?

• SQL이랍시고 만들긴 만들었는데 내 전문 분야도 아니고 누구한테 물어볼 수도 없고 참...

• 엣다 모르겄다. 팀장님한테 짜 달라고 하지 뭐.

  
  

어쩌다 선행 프로젝트 사례를 리뷰라도 하고 있노라면, 프로그래밍 소스보다 SQL 쿼리수가 더 많고 더 복잡한 경우도 허다합니다.

• 분명 내가 못하는 건 아닌데 왜 이렇게 DB가 싫어지지? 배웠는데 분명! 보면 볼수록 도대체 이걸 다 어떻게 만든 거야?

애써 배운 SQL에 대한 기초 지식과 이론에도 불구하고 적절히 써먹은 적이 없기 때문에 그렇습니다. SQL은 실제 프로젝트가 아니라면 다양한 경험을 해보기 어렵습니다. 개발 DB는 이래서 안 되고 운영 DB는 저래서 안 되고, 근데 또 개인 PC DB도 쓰지 말라 하고...

또한 SQL은 일반 프로그래밍 언어와는 다르게 사용하는 사람마다 이게 정답이다, 저게 정답이다라는 개인적 의견이 강한 특성이 있고 더불어 데이터 구조에 익숙한 만큼 활용도가 높아지므로 SQL만 알아서는 데이터베이스 개발 업무를 다루기가 쉽지 않습니다. 즉, 다양한 시스템과 환경에 대한 실무 경험이 적으면 적을수록 맨땅에 헤딩하는 기분만 잔뜩 들게 마련입니다.

강좌를 따라오다 진행을 잠깐 멈추고 생각해 보세요.

• 만약 나라면, 이 경우 데이터를 어떻게 만들려고 했을까?

• 테스트 데이터가 제공하는 경우의 수가 많을수록 좋다면 내가 직접 만들 수 있는 경우의 수는 얼마나 될까?

맞습니다. 프로그래밍과 데이터를 다루는 영역은 큰 차이가 있습니다. 프로그래밍을 로직이라고 한다면 데이터는 경험입니다. 왜냐하면 사람 살면서 발생하는 일들만큼 많으니까요. 그래서 경험이 중요하다고 하는 것이며 따라서 SQL만 배워서는 적응이 쉽지 않은 것입니다.

강좌에서 제공하는 프로젝트는 몇 안 되지만 '미리 맨땅에 헤딩하는 경험'을 선사합니다. 전부 데이터 가공과 쿼리 처리입니다. 에디터도 잘 쓸 줄 알아야 하고 테이블도 자유자재로 만들고 지울 수 있어야 하며 별의별 예외 경우들도 고민해야 합니다. 분명 프로그래밍을 짤 때와는 다른 양상입니다. 처음으로 되돌아가기를 수십 수백 회, 끝났다는 생각이 들어도 여전히 프로그래밍 작업은 남아있을 뿐입니다.

하지만 테스트 데이터 속에 다양한 경우를 더 많이 심으려 욕심을 내면 낼수록 후속 프로그래밍은 쉬워집니다. 왜냐하면 데이터를 만드는 과정 속에서 프로그래밍 로직이 이미 짜이고 예상되며 머릿속 코딩이 이루어졌기 때문입니다. 그걸 보통 선임들이 일컬어, '경험'이라 부르는 것일지도 모르죠.

점차 여러분은 '설계'라는 것의 중요성도 데이터적인 측면에서 접근할 수 있습니다. 지금껏 잘못된 설계는 프로그래밍으로 커버칠 수 있다는 믿음이 위험하다는 사실도 직면합니다. 그래서 설계 단계에 더 많은 노력과 수고와 세심함을 바치게 될지도 모릅니다. 어때요, 누군가와 닮아가지 않나요? 부러운 선임 실력자들의 모습 말입니다.

좋은 프로그래머란, 많은 언어와 기술을 다루기보단 다양한 데이터 환경을 다루어 온 사람이라 생각합니다. 당장 시장, 회사에서 자신의 가치를 높이는 것도 중요하지만 이 일을 업으로 삼아 오랜 기간 살아가려 한다면 결국 도달하는 곳은 데이터 분야가 아닐까 합니다.

이번 강좌를 통해 여러분만의 실무적 데이터, SQL 접근법을 찾아낼 수 있기를 바랍니다. 정답은 없지만 자신만의 해답은 꼭 있으니까요.

과정 및 내용

섹션 1  스터디 카페 등록 시 필요한 DB 내부 시스템

1. 스터디 카페를 찾다

   • 스터디 카페 서비스를 소개합니다.

   • 키오스크 메뉴와 요금제를 살펴봅니다.

2. 키오스크 앞에 한참을 서서

   • 고객이 등록 시 필요한 DB구조를 ERD로 직접 그립니다.

3. 머릿속으로 그려보는 결제 너머 세상

   • 설계된 ERD를 바탕으로 테이블을 생성하고

   • 현실에 가까운 가상(테스트) 데이터를 발생해 입력합니다.

4. 내가 하는 행동 모두가 데이터로

   • 발생된 데이터를 바탕으로 가상 통계 데이터를 조회합니다.

   • 이때 간단한 통계 쿼리를 만들어 봅니다.

섹션 2  웹소설에서 핵심이 되는 테이블과 데이터 구조

1. 언젠가 내가 쓴 소설이 팔린다면

   • 웹소설 및 판매 웹사이트 소개

   • 초기화면 > 상세화면 > 회차조회 > 통계화면

2. ERD라는 세계관, 테이블이라는 등장인물

   • MySQL워크벤치를 통한 ERD 그리기

   • 마스터/참조/실적 테이블에 대하여

3. 발단은 기간 데이터, 전개는 참조 테이블

   • 장르/완결여부/연재형태/태그정보 테이블

   • 기간 데이터(영/한 아이디 테이블) 및 관련 함수에 대하여

4. 주인공과 등장인물의 집합체, 웹소설 정보 테이블

   • 웹소설 정보 모든 컬럼값에 대한 가상 데이터 단계별 생성

   • 참조 테이블을 이용한 데이터값 코드화 방법

5. 대사와 액션, 회차 정보 테이블

   • 회차 정보 모든 컬럼값에 대한 가상 데이터 단계별 생성

   • 선정된 소설 한 편을 활용해 DB 업로드 및 회차별 분할 가공

   • 연재 요일별 회차 등록

6. 스토리 그 자체, 실적 테이블

   • 연재요일 정보 가상 데이터 생성

   • 회차 조회수 통계기반 가상 데이터 생성

7. 짧지만 한 편의 소설 에필로그, 통계 쿼리

   • 조회수 시간별 누적 합산값

   • 일 N시간 단위로 나누어서 합산하는 SQL

   • N(1,2,3,4,6,12,24) 시간 단위로 나누어서 조회수 합산

   • N일 단위로 묶어서 조회수 합산하는 방법

     
     

강좌 요약

• 스터디 카페에서 키오스크를 통해 등록할 때 필요한 DB시스템을 설계합니다. 더불어 가상(테스트) 데이터를 입력한 후 통계까지 조회할 수 있는 쿼리를 작성합니다.

• 웹 소설 사이트의 초기화면, 소설 한 편에 대한 상세 정보 및 회차별 조회 기능 구성에 필요한 ERD를 그려봅니다. 가상 데이터를 입력하고 통계 데이터를 생성하여 조회합니다.

• 유데미를 통해 수강하신다면 광고 없는 환경 + 소스 활용 가능한 교안 파일이 함께 제공됩니다. 강좌 구매 시 꼭 참고하세요.

TAKE THIS COURSE