数据库时间戳字段的命名建议

发布于 2024-08-23 06:59:55 字数 445 浏览 5 评论 0原文

创建数据库表时,在尝试命名时间/日期/时间戳字段时,我经常会遇到困难。有时很简单,例如编辑日期和到期日期...但通常并不那么容易。我不喜欢在字段名称中重复表名称,因为它看起来很多余。如果您有一个 posts 表,您的时间戳字段应该是 post_date 吗?显然我们不应该(不能?)使用日期/时间/时间戳作为字段名称,尽管有时如果我们有选择的话它们似乎是最好的选择。

命名与时间相关的字段是否有逻辑命名约定?由于这个问题可能没有明确的答案,所以我从一开始就对其进行了维基百科。将其全部输入后,看起来微不足道且愚蠢,但希望过去曾为字段名称而苦恼的其他人会表示同情。

编辑:

作为一个相关的后续问题,在处理不仅仅包含日期组件的日期时间/时间戳数据时,您是否在字段名称中使用“时间”或“日期”(DownloadDate与下载时间与其他时间相比)?

When creating database tables I'm often stumped when trying to name my time/date/timestamp fields. Sometimes it's easy, like edit_date and expiration_date... but often it's not as easy. I don't like repeating the table name in the field names because it seems redundant. If you have a posts table, should your timestamp field be post_date? Obviously we shouldn't (can't?) use date/time/timestamp for field names, although sometimes they seem like the best choice if we had the option.

Is there a logical naming convention for naming time-related fields? As this question is probably not definitively answerable I went ahead and wiki'd it from the get-go. Having typed it all out it seems trivial and silly, but hopefully there's someone else out there that has agonized over field names in the past that will sympathize.

Edit:

As a related follow-up question, do you use 'time' or 'date' in your field names when dealing with datetime/timestamp data that has more than just the date component to it (DownloadDate vs. DownloadTime vs. something else)?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

极致的悲 2024-08-30 06:59:55

CreatedOn、CreateDate、ModifiedOn、ModifiedDate

是一些建议

CreatedOn, CreateDate, ModifiedOn, ModifiedDate

are a few suggestions

蝶…霜飞 2024-08-30 06:59:55

为了下游使用的一致性,“内务管理”日期最好在所有表中命名为相同的名称,例如 DateCreated 和 DateModified。其他日期将更能说明其用途,并且特定于某个操作,例如开票日期、销售日期等。

The "housekeeping" dates are best named the same in all tables for consistency in the downstream usage, e.g. DateCreated and DateModified. Other dates will be more indicative of their usage and will be particular to an action, e.g. DateInvoiced, DateSold, etc.

梦里寻她 2024-08-30 06:59:55

创建日期
修改日期
发布时间
更新时间
最后更新时间
创建时间
modificationTime

这些属性也是一些基本属性...它们应该位于所有表中(可能有例外)...如果将表映射到对象...这两个应该是基类的一部分(连同 UID)

DateCreated
DateModified
PublishTime
UpdateTime
LastUpdateTime
creationTime
modificationTime

These properties are also some of the basic properties ... and they should be in all the tables (there can be exception) ... if you are mapping the tables to objects ... these two should be part of the base class (along with UIDs)

月亮是我掰弯的 2024-08-30 06:59:55

简单地“创建”等。更短,没有驼峰式大小写,没有下划线。这种情况很常见,因此无需直接在名称中添加更多信息,例如“日期”、“日期”或“日期”。

simply "created", etc. Shorter, no camel case, no underscore. It is frequent enough that it is unnecessary to add more information directly into the name, like "date" or "on" or "at".

驱逐舰岛风号 2024-08-30 06:59:55

我更喜欢使用它,因为它的简单性和对记录创建、更新或修改和访问的时间的描述

date_created
更新日期或修改日期
date_accessed

检查一下,看看它如何减轻您命名和访问数据的压力。

I would prefer to use this because of its simplicity and description to when a record was created, updated or modified and accessed

date_created
date_updated or date_modified
date_accessed

Check this out and see how it ease your stress of naming and accessing data.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文