当我想创建一些时间戳字段(或其他日期/时间样式字段)时,给它们命名的最佳方法是什么?我应该只放record_timestamp吗?

#1 楼

您应该描述列的用途,而不一定是数据类型。您可以在名称中包括日期/时间/时间戳,但还应包括含义。例如,


CreationDate
StartDate
StatusTime
已访问
已更新


添加日期/时间/时间戳和当添加的缺席将与另一列冲突时,在结尾处这样做特别有用。例如,一个表可能同时需要一个Status和一个StatusTime。

评论


只是加上我的两分钱。我使用了许多旧的MRP系统,发现经常使用CreatedOnUtc和UpdatedOnUtc。

– Geovani Martinez
16-09-20在1:40

我认为“已访问”和“已更新”可能是模棱两可的,因为它也可能意味着布尔值(至少在Ruby世界中)

– Artur Beljajev
17-6-27 at 13:26



@GeovaniMartinez可能会令人困惑,因为许多SQL数据库(包括PostgreSQL)存储在UTC并读取客户端的时区。

–埃文·卡洛尔(Evan Carroll)
17年6月2日在14:11

如果时间单位应该是UTC vs System Local,则在列名称中指定_UTC。感谢我们所有人,他们以后必须维护代码。

–乔纳森·菲特(Jonathan Fite)
18年1月30日在17:55

访问和更新可能与世界卫生组织的访问或更新不明确,这是很普遍的事情

–乔·菲利普斯(Joe Phillips)
18年3月20日在15:56

#2 楼

xyz_attimestampxyz_ondate怎么样-例如start_atstart_on?从任何字段的名称了解类型(一个称为description的字段不太可能是integer)-但是能够分辨出timestampdate之间的区别通常会有所帮助。

#3 楼

我使用:


created_at
updated_at


评论


“在”也可以暗示位置。那么“何时”而不是“在”呢?

– Sepster
13-10-22在1:12

在法律和财务文件中经常使用“ at”或“ at at”来指代什么时候发生。 english.stackexchange.com/questions/112770/…

–尼尔·麦圭根(Neil McGuigan)
2013年12月19日19:05



它仍然可能是模棱两可的。如果您需要知道更新的时间和位置怎么办? Updated_at可能是。但是我认为答案是,与命名一样,使用最简洁的名称可以消除所有现实的歧义。即如果在特定情况下可能会造成某种混乱,请消除它,但不要使用比该名称更冗长的名称

– nafg
17 Mar 17 '17 at 0:22

怎么样?尽管它意味着一个日期超过一个时间,但它仍然很明显

–乔·菲利普斯(Joe Phillips)
18年3月20日在15:57

#4 楼

我查看了您的配置文件,它说您使用的是SQL Server,在SQL Server中,TIMESTAMP数据类型与日期或时间无关,它用于标记行的版本。这对于识别从给定时间点修改了哪些行非常有用。

如果使用TIMESTAMP,则不必指定列名,SQL Server会创建一个列“ TimeStamp” “ 为了你。但是建议使用“ ROWVERSION”数据类型,在这种情况下,您必须指定列名称。

像这样的列的最佳名称是什么?这要看情况了,我会使用像VersionStamp,RV之类的东西。我认为重要的不是您的名字,而是您是否一贯地使用它。

HTH

参考:
http://msdn.microsoft.com/zh-cn/library/ms182776(v = sql.90).aspx

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

#5 楼

我发现在方法命名和规范(RSpec)方面使用create_timeupdate_timeexpire_time之类的列名可以提高可读性。

#6 楼

我更喜欢为日期戳使用DT的前缀。例如:DTOpened,DTClosed,DTLastAccessed。这使我可以列出所有DTxxxx,以便快速参考给定表中的所有日期戳。

#7 楼

我为Texas Instruments工作,在他们的系统上,他们使用xxxx_dttm

#8 楼

我更喜欢使用已经存在的约定。

Unix和编程语言对mtime的修改时间有广泛接受的约定。

对于创建时间,


BSD和Windows使用birthtime
Windows也使用创建时间
xstat使用btime
crtime

JFS和btrfs使用otime(不要问,猜测“原点” “)。

因此,对我来说,我选择mtimecrtime来获取元数据。

对于用户提供的数据,我会选择该字段表示的内容。如果是生日,我只说user_birthday。就精度而言,对于某些人来说,似乎过于精确。您可以将birthdate存储为时间戳(毕竟,从技术上来说,您是一天中的某天出生的),但是SQL规范已将精度从较高的精度转换为较低的精度,因此,如果您使用的是体面的数据库,则不应问题。在您的应用程序本身中,您始终可以在需要时截断。也就是说,我永远也不会去birthday_date

#9 楼

为了保持列名之间的一致性,我建议您使用以下语法:

dateCreated
dateUpdated
dateAccessed
dateStarted
date...


#10 楼

正如@Evan Carroll所建议的那样,请遵循现有的标准,除非您有充分的理由打破这种模式。

我使用* _on和* _by是因为它有助于我使其与行中的何时何地保持一致:

- created_on & created_by
- updated_on & updated_by
- deleted_on & deleted_by -- soft delete
- approved_on & approved_by


#11 楼

没有确切的正确方法,唯一重要的是要在代码库和数据库之间保持一致,以免开发人员感到困惑。
确切的命名取决于语言约定,但我可以选择以下其中一种:
Python, Java, ORACLE/Postgresql

created_at, createdAt, CREATED_AT // Time when the record was created
updated_at, updatedAt, UPDATED_AT // Time when the record was last modified
started_at, startedAt, STARTED_AT // Some other record time

Or

create_time, createTime, CREATE_TIME
update_time, updateTime, UPDATE_TIME
start_time, startTime, START_TIME


几乎所有字段都存储为时间戳,有些字段需要作为日期,但通常它们与业务领域相关性更高,可以根据即将到来的请求进行命名

生日
realase_date
business_day

所有要存储在UTC中的时间戳字段。

#12 楼

我会使用有意义的前缀和_TSMP作为后缀,例如CREATION_TSMP或LAST_UPDATE_TSMP