타임 스탬프 필드 이름을 어떻게 지정해야합니까?


57

타임 스탬프 필드 (또는 다른 날짜 / 시간 스타일 필드)를 만들 때 가장 좋은 방법은 무엇입니까? 그냥 record_timestamp를 넣어야합니까?

답변:


42

데이터 유형이 아니라 열의 목적을 설명해야합니다. 이름에 날짜 / 시간 / 타임 스탬프를 포함 할 수 있지만 그 의미도 포함해야합니다. 예를 들어

  • 생산 일자
  • 시작일
  • StatusTime
  • 액세스
  • 업데이트

마지막에 날짜 / 시간 / 타임 스탬프 등을 추가하면 추가가 없으면 다른 열과 충돌 할 때 특히 유용합니다. 예를 들어, 테이블에는 Status 및 StatusTime이 모두 필요할 수 있습니다.


2
그냥 내 두 센트를 추가합니다. 많은 레거시 MRP 시스템과 협력하여 CreatedOnUtc 및 UpdatedOnUtc가 자주 사용되는 것을 발견했습니다.
Geovani Martinez

6
나는 또한 (적어도 루비의 세계에서) 부울을 의미 할 수 있기 때문에, 모호 할 수있다 "업데이트", "접근"생각
아르투르 Beljajev

2
PostgreSQL을 포함하여 많은 SQL 데이터베이스로 혼란 스러울 수있는 @GeovaniMartinez는 UTC에 저장하고 클라이언트 시간대로 읽습니다.
Evan Carroll

시간 단위가 UTC 대 시스템 로컬 인 경우 열 이름에 _UTC를 지정하십시오. 나중에 코드를 유지해야하는 우리 모두에게 감사합니다.
Jonathan Fite

WHO 액세스 또는 업데이트로 액세스 및 업데이트가 모호 할 수 있습니다. 이는 추적하는 것이 일반적입니다.
Joe Phillips

27

방법에 대한 xyz_atA의 timestampxyz_onA의 date필드 - 예를 들면 start_atstart_on?

일반적으로 필드 이름에 데이터 유형을 포함하지 않으려합니다. 필드 이름에서 유형에 대해 알아야 할 내용을 추론 할 수 있으면 훨씬 좋습니다 (필드는이라고 description할 수는 없음 integer)-말할 수 있음 a timestamp와 a 의 차이 date는 종종 도움이됩니다.


16

나는 사용한다:

  • created_at
  • 업데이트 됨

2
"at"는 위치도 암시 할 수 있습니다. "at"대신 "when"은 어떻습니까?
Sepster

1
"at"또는 "as at"은 법률 및 재무 문서에서 자주 발생하여 문제가 발생한시기를 나타냅니다. english.stackexchange.com/questions/112770/…
Neil McGuigan

3
여전히 모호 할 수 있습니다. 업데이트 된 시간과 위치를 알아야하는 경우 어떻게합니까? updated_at둘 중 하나 일 수 있습니다. 그러나 대답은 항상 이름 지정과 마찬가지로 모든 현실적인 모호성을 제거하는 가장 간결한 이름을 사용한다고 생각합니다. 즉, 특정 상황에서 특정 혼동이 발생할 가능성이있는 경우이를 제거하되 필요한 것보다 더 자세한 이름은 사용하지 마십시오.
nafg

1
"온"은 어때? 그것은 날짜보다 시간을 의미하지만, 여전히 분명하다
Joe Phillips

6

프로필을 살펴본 결과 SQL Server에서 작업하고 SQL Server에서 TIMESTAMP 데이터 형식은 날짜 또는 시간과 관련이 없으며 행의 버전을 스탬프하는 데 사용됩니다. 이것은 주어진 시점에서 어떤 행이 수정되었는지 식별하는 데 매우 유용합니다.

TIMESTAMP를 사용하는 경우 열 이름을 지정할 필요가 없으며 SQL Server가 "TimeStamp"열을 만듭니다. 그러나 "ROWVERSION"데이터 형식을 사용하는 것이 좋으며이 경우 열 이름을 지정해야합니다.

이와 같은 열에 가장 적합한 이름은 무엇입니까? 그것은 달려 있고 VersionStamp, RV 등과 같은 것을 사용할 것입니다 ... 내가 중요하게 생각하는 것은 이름을 지정하는 방법이 아니라 보드 전체에서 일관되게 사용하고 있다는 것입니다.

HTH

참조 : http://msdn.microsoft.com/en-us/library/ms182776(v=sql.90).aspx

http://msdn.microsoft.com/en-us/library/ms182776.aspx


3

나는 같은 열 이름을 사용하는 것을 발견 create_time, update_time그리고 expire_time그 방법 이름 지정 및 사양 (RSpec에) 올 때 가독성에 연결됩니다.


1

날짜 스탬프에 DT 접두사를 사용하는 것을 선호합니다. 예를 들면 다음과 같습니다. DTOpened, DTClosed, DTLastAccessed. 이를 통해 주어진 테이블의 모든 날짜 스탬프를 빠르게 참조 할 수 있도록 모든 DTxxxx를 나열 할 수 있습니다.



1

이미 존재하는 규칙을 사용하는 것을 선호합니다.

유닉스와 프로그래밍 언어의 널리 허용 규칙이 mtime에 대한 수정 시간

창조 시간 동안

  • BSD 및 Windows 사용 출생 시간
  • Windows는 또한 생성 시간을 사용합니다
  • xstat 사용 btime
  • ext4 사용 crtime
  • JFS와 btrfs는 사용합니다 otime( "접수"를 추측하지 마십시오).

그래서 나를 위해, 내가 선택 mtime하고, crtime메타 데이터.

사용자가 제공 한 데이터의 경우 필드가 나타내는 내용으로 이동합니다. 생일이라면 그냥 말합니다 user_birthday.

정밀도에 관해서는, 어떤 사람들에게는 너무 많은 정밀도에 매달리는 것 같습니다. 당신은 birthdate타임 스탬프로 저장할 수 있지만 (기술적으로 태어난 날마다) SQL 사양은 높은 정밀도에서 낮은 정밀도로 캐스트되었으므로 적절한 데이터베이스를 사용하는 경우 문제가되지 않습니다. . 앱 자체에서 필요할 때 언제든지자를 수 있습니다. 즉, 나는 결코 가지 않을 것 birthday_date입니다.


0

CREATION_TSMP 또는 LAST_UPDATE_TSMP와 같이 의미있는 접두사와 _TSMP를 접미사로 사용했습니다.


0

열 이름에 대한 일관성을 유지하려면 다음 구문을 제안합니다.

dateCreated
dateUpdated
dateAccessed
dateStarted
date...

0

@Evan Carroll이 제안한 것처럼 패턴을 깰 이유가 없으면 기존 표준을 따르십시오.

이것이 새로운 것이라면 가장 적합한 답변을 따를 수 있습니다.

* _on 및 * _by를 사용하면 언제 어디서 누가 행에 대해 일관성을 유지할 수 있습니다.

- created_on & created_by
- updated_on & updated_by
- deleted_on & deleted_by -- soft delete
- approved_on & approved_by
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.