일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- react
- 자바예외
- 이펙티브자바
- 인덱스
- 알고리즘
- 인프런백기선
- AWS RDS
- vue.js
- jpa
- mysql
- MariaDB
- 자바스터디
- SQL쿡북
- 이펙티브 자바
- 자바
- CleanCode
- 혼공SQL
- 도메인 주도 개발 시작하기
- 자료구조
- AWS
- aop
- java
- 네트워크
- 인프런김영한
- 이팩티브 자바
- 알고리즘분석
- DDD
- 스프링부트와AWS로혼자구현하는웹서비스
- 클린코드
- 기술면접
- Today
- Total
목록분류 전체보기 (272)
기록이 힘이다.
import org.springframework.data.annotation.CreatedDate; import org.springframework.data.annotation.LastModifiedDate; import org.springframework.data.jpa.domain.support.AuditingEntityListener; import javax.persistence.Column; import javax.persistence.EntityListeners; import javax.persistence.MappedSuperclass; import java.time.LocalDateTime; /** * 공통 매핑 정보를 가진 Entity */ @MappedSuperclass // 상속받은 e..

주요 엔터티는 개념 모델링 단계에서 이력 엔터티를 고려하는 것이 현실적으로 효율적이다. 원천 데이터를 먼저 명확하게 설계해야 한다는 점을 염두에 두어야 한다. 이는 마치 정규화를 한 후에 비정규화를 하는 것과 같은 이치다. 실무에서 주로 사용하는 방법으로 논리 모델링이 끝난 이후나 물리 모델링 기간에 이력 데이터를 설계하는 것이다. 필자는 이 방법을 사용하지 않는데, 이럭 데이터 관리 방법에 따라 모델 구조가 바뀔 수 있기 때문이다. 또 한가지 중요하게 고려할 점은 모델링 기간이다. 본질 데이터를 먼저 정의하고 이력 데이터를 나중에 정의하는 프로세스는 시간이 오래 걸린다. 이력데이터를 설계하는 두 가지 방법은 이력 데이터를 별도의 엔터티에서 관리하는 방법이 있으며, 이력 데이터와 원천 데이터를 함께 관리..
https://www.baeldung.com/jpa-many-to-many

식별자 속성과 비식별자 속성 사원 엔터티에서 사원번호 속성은 주 식별자다. 그리고 사원주민등록번호 속성은 대리 식별자며 소속부서번호 속성은 외래 식별자다. 따라서 사원번호.사원주민등록번호 속성은 식별자 속성이고 사원명.입사일자.소속부서번호.퇴사일자.휴대전화번호 속성은 비식별자 속성이다. 후보 식별자 주 식별자가 될 가능성이 있는 식별자를 의미한다. 모든 식별자는 주 식별자가 될 수 있는 후보이므로, 식별자와 후보 식별자는 사실상 동일어다. 후보 식별자가 업무 식별자보다 더 넓은 개념이다. 주 식별자 주 식별자는 엔터티에 하나만 존재하는 대표 식별자다. 흔히 주 식별자와 주 키라는 용어는 동일하게 사용한다. PK는 테이블에 지정된 물리적인 제약을 의미한다. 이에 반해 주 식별자는 논리적으로 인스턴스를 식별..

통합이 대세인가? 데이터가 증가하는 것은 성능과 유관하다.데이터 통합 시 실무자들이 가장 우려하는 것은 성능이다. 지나치게 일반화하면 데이터의 정체성이 희석된다. 파티와 같이 성격이 다른 데이터를 지나치게 일반화해서 통합하는 것은 의도적인 통합니다. 의도적인 통합과는 다르게 의도적이지 않은 통합이 있다. 데이터 정의에 근본적인 문제구 있어 분간이 힘들다. 다른 데이터라도 정의만 유사하게 선언하면 그럴듯한 통합처럼 보인다. 이런 통합은 아예 틀린 것이다. 이에 대한 해법은 우선 데이터 정의를 제대로 하는 것이다. 먼저 정규화를 하여 엔티티 정체성을 명확하게 해야한다. 의도하지 않은 통합, 스스로도 잘 모르는 통합, 통합을 위한 통합을 하지 않기 위해서는 데이터 정의를 제대로 해야 한다. 필자는 주로 실체...

데이터 모델을 제대로 설계하기 위한 근본적인 해결책은 정규화뿐이다. 시스템에 따라 정규화가 필요없을 수 있지만, 그건 필요에 따른 선택일 뿐이며, 이마저도 원칙에 바탕을 둔 선택이다. 정규화란? 식별자에 종속된 유사한 속성들을 모으고, 종속되지 않은 독립적인 속성들은 분리하여 속성을 명확히 구별하는 것이 정규화다. 정규화를 수행하는 것은 중복 속성을 제거하기 위함이지 액세스 성능을 최적화하기 위함은 아니다. 정규화를 하면 엔터티는 분해되고 중복 속성은 제거되기 때문에 데이터를 추출할 때 성능이 떨어질 수 있다. 더이상 추가할 속성이 없는 모델보다, 제거할 속성이 없는 모델이 완벽한 모델이다. 중복을 최대한 제거하는 과정이 정규화다. 함수 종속이란? 함수 종속은 관계형 모델을 설계할 때 가장 중요한 데이터..

엔터티 정의방법 - 원천 데이터인가? - 스스로 존재하는 최초의 데이터이다. - 고객이나 사용자가 직접 입력함으로써 생성된다. 즉 화면에서 입력한다. 반면에 가공 데이터는 주로 프로그램에 의해 생성된다. 배치 프로그램이나 데이터 복제 프로그램에 의해 생성된다. 원천 데이터끼리는 관계가 활발하게 존재하는 반면, 원천 데이터와 가공 엔터티, 또는 가공 엔터티끼리는 참조 무결성 관계가 거의 존재하지 않는다. 원천 데이터는 정규화를 철저히 수행해야 하는 데이터다. 가공 데이터는 비정규화가 비교적 빈번하게 수행된다. 꼭 필요하지 않은 실체화된 뷰는 자원을 낭비하고, 성능을 저하시킬 수 있으므로 가공 데이터와 마찬가지로 주의가 필요하다. 가공 엔터티에 사용된 값은 원천 엔터티의 값이 바뀌면 수정해야 한다. 데이터 ..
- 사용자 식별 관련 정보를 전달하는 HTTP 헤더들 - 클라이언트 IP 주소 추적으로 알아낸 IP 주소로 사용자를 식별 - 사용자 로그인 인증을 통한 사용자 식별 - URL에 식별자를 포함하는 기술인 뚱뚱한 URL - 식별 정보를 지속해서 유지하는 강력하면서도 효율적인 기술인 쿠키 쿠키는 사용자를 식별하고 세션을 유지하는 방식 중에서 현재까지 가장 널리 사용하는 방식이다. 쿠키만으로 하기 힘든 일에는 앞서 설명한 기술들을 함께 사용하기도 한다. 쿠키는 세션 쿠키와 지속 쿠키 두 가지 타입으로 나눌 수 있다. 세션 쿠키는 사용자가 사이트를 탐색할 때, 관련한 설정과 선호 사항들을 저장하는 임시 쿠키다. 세션 쿠키는 사용자가 브라우저를 닫으면 삭제된다. 지속 쿠키는 삭제되지 않고 더 길게 유지될 수 있다...