TIL - 0903-0907

Posted on | In | 0 comments

0903

오늘 한 일

  • sort 부분 공부
  • 면접 관련해서 정리

0904

오늘 한 일

  • 인터뷰.

인터뷰에서 나왔던 질문들

  • 대부분 내가 이력서에 적었던 것들 위주로 물어봤다.
  • python /django / git 에 자신있는 부분
    • 결과적으로 왜 그렇게 로직이 움직이는지 혹은 설계가 되었는지에 집중해서 공부하자
  • HTML, HTTP 와 관련한 통신 쪽 부분도 공부를 더 해야할꺼같다.
  • 내 프로젝트에서 S3가 필요가 없을꺼란 이야기 -> NGINX단에서 SERVING 하는 부분으로 로직 수정
      1. nginx에서 /static/경로 -> /s3.amazonaws.com/<경로>
      1. s3 자체에서 바로 static 파일을 주게 하는 법
      1. CDN 참고자료
  • 기초적인 용어 정리가 한번 필요하다
  • 알고리즘은 공부하자 ㅋㅋㅋ
  • 신입개발자에게 정말 좋은 기회였다. 아무래도 내가 무엇이 부족하지도 모르고 정말 무엇이 질문으로 나올지 모르는 상황에서 뭘 해야하나 고민만 됬었기 때문이다. 참 감사하게도 정말 공부할게 천지다. 게으름피우지 말고 기본적인 공부도 하면서 천천히 다 돌아보자. 감사한건 집에 그런 책이 많다는것 ㅋㅋㅋ 전공책부터 뒤적뒤적해보자!

0905

0906

오늘 한 일

  • 정보처리기사 실기 3회차 신청
  • 알고리즘 문제해결전략 - ch4 읽고 정리하기 - 4.7 부분 다시 공부할 것
  • redis-django 튜토리얼 따라하기
  • 다음주까지 cache 붙여서 하기 -> 알고리즘 공부

0907

하이어링데이 참여 후기

  • 생각보다 많은 기업이 백엔드를 요구한다는 것을 알 수 있었다. 물론 몇몇회사의 경우 python을 사용해서 요구하는 경우도 있었던 것 같다. 대부분 기술 면접을 보기보단 회사 소개 그리고 마음에 들면 한번 지원해봐라라는 그런식의 공간이었다.
  • 기술면접으로 들어왔던 질문들
    • 컴퓨터공학복수 전공 : 수강했던 과목, 재밌었던 과목
    • RDBMS : RDBS 특징, 트랜젝션(많은 사람들이 접속했을 경우에 대한 이야기), 외래키 (이게 왜 중요한지)-무결성, ORM과의 차이점
    • 도커 : 만들어진 배경, 정확히 이게 무엇인지에 대해서, 그리고 편리함
    • celery : 왜 사용했는지..
  • 내가 부족한 건 결과적으로 컴퓨터공학지식이 부족한 것이다. 그래도 웹에서 연관지을 수 있는 부분은 네트워크부분 이런쪽부터 차근차근 공부하자
<FK의 생성에 따른 장점>
1. RDBMS의 사용개념에 바탕한 효율적인 테이블 간의 Relation 설계를 바탕으로 각 Relation의 관계를 읽기 쉽다. 즉, 다시말해서 테이블의 추가, 삭제, 변경 등에 따른 DB구조의 관리가 용이하다. (물론, FK 유지를 위한 작업량은 조금 많아 질 수 있을 지 모르지만..) (관리 측면)
2. FK로 참조되는 테이블은 대개 대형테이블이 아니며, Join 등에 따른 실행시 부담이 적다. 대개 query를 잘못 작성해서 Perfomance의 문제가 발생하기도 한다. 즉, FK를 잡아주지 않고, Index만을 가지는 경우와 비교해서 특별히 Performance의 차이를 보일정도는 아니라고 생각한다. (개인적으로..) (성능 측면)
3. 1.에서와 같이 테이블 설계가 이루어진다면, FK의 구현은 별것 없다. 기존 시스템에서 FK를 구현할 경우, 각 테이블의 Data 무결 상황, Query의 검토 등이 이루어져야 할 것이다. (구현 측면)
<FK의 생성에 따른 단점>
1. 제약에 따른 Resource의 사용(trigger, check 등에 비해 현저히 적음)
2. 고려해야 할 항목이 늘어났음.. -_-;; 코드의 변경 등의 경우, FK의 참조순서를 고려해서 변경을 실행해야 함. (근데, 이건 단점이라기 보다는 무결성을 유지해 나갈 수 있다는 점에서 장점일 수 있겠네요. 코드를 아무렇게 변경해도 된다면, 변경 이전 데이터에 대한 데이터 무결성이 무너지는 순간이 되겠죠..)
3. DB 설계가 중요해짐. DB 뿐만 아니고 뭐든지 설계가 가장 중요합니다.
결론 속도면이나 구현면을 고려할 때, FK를 생성하는 것과 Index만을 생성해서 app등에서 데이터 무결성을 유지하는 것과 비교한다면, FK를 생성하는 것이 유리하다고 생각합니다. 물론 관리측면에서도 FK를 유지하는 것이 좋습니다.
즉, RDBMS를 사용한다면, Relation관계를 가지는 DB 설계가 기본이며, FK를 설정한다고 해서 Performance 등에 영향을 줄 정도는 아니라고 생각합니다.

<ORM: Object Relational Mapping>
OOP 언어에서 RDBMS를 연동할 때, 클라이언트 라이브러리/SQL을 사용하여 구현할 수 있다
하지만 ORM을 사용하면, 좀더 높은 생산성(빠른 개발속도, 짧은 개발기간)으로 개발할수 있다
즉, ORM의 사용목적/이유는 생산성에 있는 것이다