Today's Dev Notes(2019-01-14)

안녕하세요, Brad입니다. 오늘 공부한 것 정리해볼게요.

 

Q & A

• 기본키 설정 관련

  • 기본키 설계의 중요성

    • Entity의 @Id 가 반드시 Long 타입으로 설정되는 것은 아닙니다.
    • Primary키로 사용하기로 했다면 그 키는 절대 바뀌는 일이 없는 것으로 생각해야합니다. 왜냐하면 변경시 엄청나게 많은 곳에서 바꿔줘야하는 곳이 많기 때문입니다.
    • 데이터는 한번 쌓기 시작하면 변경이 힘들기 때문에 기본키를 무엇으로 설정하는지가 정말 중요합니다.

  • PK를 순차적으로 구현하는 것이 좋다?

    • 보안적으로 PK을 노출하는 것이 좋지 않겠다고 판단할 때는 Random값으로 PK를 부여할 수도 있습니다.
    • Romdom값 생성하는 것은 JPA에서 해주는 것을 사용할 수도 있지만 별도로 클래스를 만들어서 그곳에서 생성하는 값으로 Id로 부여할 수도 있습니다.

• User 프로필 이미지 Default는 어떻게 설정할까요?

  • 상수값으로 관리하던 값들은 Spring에선 'application.properties'에서 별도로 설정해놓을 수 있습니다.

    • application.properties 안에 default.profile.image=./images/default.jpg 로 설정합니다.

  • 왜 이렇게 빼놓는 것이 좋을까요?

    • 이후 변경시 소스코드 내 일일이 변경할 필요없이 설정파일의 값만 바꾸면 되기 때문입니다.

  • 어떻게 해당 설정값을 가져올 수 있을까요?

    • 아래와 같이 설정할 수 있습니다.

    @Value("${default.profile.image}")
    private String defaultImage;
    

    • 주의할 점은 User와 같은 Entity에선 적용이 안된다는 것입니다! 왜냐하면 User는 스프링에서 관리하는 Bean이 아니기 때문입니다. @Service 내에선 사용할 수 있겠죠.

  • 참고) application.properties 관리

    • @ConfigurationProperties(prefix = "eval.security") 로 설정하고 클래스로 분리한 후 setter / getter설정을 통해 해당 설정값을 대입시킬 수 있습니다.
    • 이 부분은 좀 더 살펴봐야할 것 같네요.

• messages.properties 사용

  • Exception 내에 message를 적는 것도 하드코딩이라고 할 수 있습니다. 왜냐하면 그 에러처리도 많은 곳에서 사용하고 있기 때문입니다.

  • messages.properties 를 사용하기 위해선 @Configuration 에서 별도의 설정이 필요합니다.

  • @Valid 이외에 Exception 메시지도 설정합니다.

  • messageSource.setCacheSeconds(30) : 에러 메시지가 바뀔때도 있기 때문에 그 외 별도 캐시 설정을 하기 위함입니다.

  • 다국어 처리

    • 브라우저에 설정되어 있는 값들을 이용하여 해당 언어 파일을 읽어올 수 있도록 설정할 수 있습니다.

    • 예를들어 'messages.en.properties', 'messages.ko.properties' 와 같이 사용할 수 있죠.

    • 주의할 점

      • 에러 메시지 뿐만 아니라 서비스에 사용되는 모든 곳(메뉴이름 등)의 이름 또한 설정해두어야 합니다.
      • 기존에 html에 하드코딩된 부분이 변수로 바뀌어야될 것입니다.

• 애노테이션

  • @Target : 어노테이션이 사용될 수 있는 위치를 말합니다.

    • TYPE : 클래스 레벨
    • FIELD, METHOD, CONSTRUCTOR 등등

  • @Retention : 어느 시점까지 어노테이션 유지할 것인지 설정하는 부분입니다.

    • SOURCE

      • 컴파일하면 사라짐니다. 컴파일하기 전까지 유효한 것입니다
      • 예) @Override

    • CLASS

    • RUNTIME

      • 가장 많이 사용됩니다.
      • 자바 리플렉션을 이용해 활용할 수 있습니다.

  • 어노테이션을 왜 쓸까요?

    • 어노테이션을 사용하기 전에는 어노테이션과 같은 설정 정보를 다 XML에 해두었습니다.
    • 하지만 분리해서 사용하다보니 소스코드와 XML 간 왔다갔다 하는 것이 힘들었고, XML내 오타, 변경시 싱크 시켜줘야하는 것이 힘들었습니다. 하지만 어노테이션을 통해 해결할 수 있죠!

• 첨부파일 관리

  • Question 과 Answer 모두에서 파일 관리를 해야한다면 각각 매핑하기 보다 Attachment 클래스를 만들어서 Question 과 Answer 각각 Attachment 와 매핑할 수 있습니다. N:N 매핑으로 중간에 다른 테이블이 하나 만들어지겠죠.
  • 현업 예전에는 전용 파일 서버를 둔 다음, 그 서버를 마운트하여 첨부파일을 저장했습니다. 하지만 요즘은 파일 서버에 API를 만들어서 이를 이용하여 파일을 저장 또는 로드합니다.

 

 

'SQL' Join과 DB Index 기초 - 징고

• 조인

  • 데이터베이스 내의 여러 테이블의 레코드를 조합하여 하나의 열로 표현

    SELECT *
    FROM employees AS emp
    JOIN departments AS dept
    ON emp.id = dept.id
    

  • INNER JOIN

    • A, B테이블의 교집합에 해당합니다

  • LEFT OUTER JOIN

    • A테이블을 말합니다.
    • 즉, 조건을 만족하는 것과 A-B부분이 나옵니다. 해당 데이터가 없으면 null값으로 나옵니다.

  • FULL OUTER JOIN

    • A, B테이블의 합집합에 해당합니다.

• 데이터베이스 Index

  • 종류

    • Primary : 중복되지 않는 유일한 키(Not nullable)
    • Unique : 중복을 허용하지 않는 유일한 키(nullable)
    • Normal : 중복을 허용하는 인덱스

  • 인덱스 정의 방법

    • 자주 조회되는 칼럼에 적용
    • 조회 시 오랜시간 소요되는 칼럼에 주로 사용

  • 어떤 Index 설정했느냐에 따라 성능 나타내는 값(ref, normal, all 등 - 추가적 학습 필요)을 확인할 수 있습니다.

  • full scan하는 것이 무조건 느리다고 할 수는 없습니다 데이터가 적은 등 특정 조건일 경우 full scan이 더 빠를 수도 있습니다.

    • 조회는 별로 없는데 추가, 수정이 많다면 인덱스를 사용하는 것이 적절하지 않을 수 있습니다.
    • 지운 데이터의 기록을 남기는DeleteHistory 같은 경우는 인덱스를 설계하는 것이 적절하지 않습니다. 조회보다는 추가가 많기 때문입니다.

  • 사실 현업에서 대용량 데이터를 가지고 체험을 해보고 인덱스 설계를 통해 시간을 줄이는 경험을 해봐야 느껴볼 수 있습니다. 책으로 백날봐야 알 수 없습니다.

   

   

좀 더 공부해야할 내용

• 인덱스는 어떤 자료구조를 사용하나요?

  • B(Balanced)-tree

• groupBy, Join

 

 

공부한 내용

• '.gitignore'에 등록했는데도 불구하고 계속 status에 나타나는 경우

  • 이렇게 되는 이유는 캐시에 있기 때문입니다. 이 경우 캐시를 지워주면 됩니다.

  git rm -r --cached .