은 내가 특별히 프로 long를 사용하는 것에 비해 java.util.Date를 사용 & 단점에, 지속 타임 스탬프의 관행에 대한 합의가 필요합니다. 이 토론의날짜 또는 시간으로 지속 시간 소인 필드를 유지 하시겠습니까?
범위 :
나에 대해서 : 나는 JPA에서 초보자로 생각하고있다. 지금까지는 프로덕션 수준의 프로젝트에 적용 할 수 없었습니다. 현재 프로젝트에서는 JPA 호출을 통해 ObjectDB (임베디드)를 사용하겠다고 약속합니다. 이 타임 스탬프과 같은 자바의 문서에서
다음 클래스는 JPA에 타임 스탬프를 지속하는 3 가지 가능한 방법을 보여준다.
TS3는 (ObjectDB 데이터베이스 탐색기, 보고서 등의) TS1과 TS2보다 사용하기 덜 편리 할 수 있습니다. 기간별 검색이 모든 세 지원되지만 쿼리 추출 일시 부품 (YEAR, MONTH, 등) TS3 지원되지 않는
기본 질의 등.
이러한 양식은 모두 휴대 할 수 있어야합니다.
TS1과 TS2는 실질적으로 동일하다.
자세한 내용은 ObjectDB manual에 제공됩니다.
당신이 코드의 의미에 대해 걱정하는 경우 추가로
http://docs.oracle.com/javase/1.4.2/docs/api/java/sql/Timestamp.html
를 java.util.Date의에 가깝게 관련되어, 타임 스탬프는 날짜입니다. 성능 및 메모리 사용량에 대해서
@Entity
public class Timestamps {
private java.sql.Timestamp ts1;
private @Temporal(TemporalType.TIMESTAMP) java.util.Date ts2;
private long ts3;
:
}
는 TS3 약간 더 효율적이다
당신은 그것을 사용하기 전에 을 java.sql.Timestamp의 사실에 대해 알고 있어야합니다 : 인스턴스 작성 클래스를 확장하고 값 구성 요소를 추가 할 Java 플랫폼 라이브러리의 일부 클래스가 있습니다
. 예를 들어, java.sql.Timestamp 는 java.util.Date를 확장하고 나노초 필드를 추가합니다. 타임 스탬프에 대한 동등한 구현 대칭을 위반 타임 스탬프 및 날짜 오브젝트가 같은 컬렉션 사용하거나 혼합하는 경우 이상한 동작이 발생할 수 있습니다 않습니다. Timestamp 클래스에는 프로그래머에게 날짜와 시간 소인을 섞어 경고하는 것에 대한 면책 조항이 있습니다. 을 별도로두면 문제가 발생하지 않지만 혼합하지 못하게 할 수있는 것은 없으며 오류가 발생하면 디버깅하기가 어려울 수 있습니다. Timestamp 클래스의이 동작은 오류이므로 에뮬레이션해서는 안됩니다.(Bloch, Effective Java, 2nd Ed.)
쿼리가 관련된 편의성과 가독성으로 인해 Date가 우승 한 것으로 생각됩니다. Long은 원시 데이터 응용 프로그램에 적용 할 수 있습니다. 검색어가 희귀하거나 수집 후 호출되는 과학, 의료 보고서 생성. –