数据库名称约定:DATETIME 列

发布于 2024-08-03 17:09:28 字数 721 浏览 5 评论 0原文

DATETIME 列的命名约定是什么(在我的例子中,使用 MS SQL Server)

对于存储行创建时间的列,CreatedDatetime 有意义,或 LastModifiedDatetime 有意义。

但对于一个简单的表,假设一个名为“事件”的表,您会创建名为:的列

TABLE Event
====================================================
EventID,                 // Primary key
EventDatetime,           // When the event is happening
EventEnabled             // Is the event is on

还是这些列名称

TABLE Event
====================================================
ID,                      // Primary key
Datetime,                // When the event is happening
Enabled                  // Is the event is on

如果您不使用这两种约定:请提供您将使用的列名称。

What is your naming convention for DATETIME columns (in my case, using MS SQL Server)

For a column that stores when the row was created CreatedDatetime makes sense, or LastModifiedDatetime.

But for a simple table, let's say one called Event, would you create columns called:

TABLE Event
====================================================
EventID,                 // Primary key
EventDatetime,           // When the event is happening
EventEnabled             // Is the event is on

or these column names

TABLE Event
====================================================
ID,                      // Primary key
Datetime,                // When the event is happening
Enabled                  // Is the event is on

If you'd use neither convention: Please provide the column name you would use.

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

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

发布评论

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

评论(9

情深已缘浅 2024-08-10 17:09:28

我通常将 DATETIME 列命名为 ACTION_WORD_on:created_on、completed_on 等。

ACTION_WORD 定义该列代表的内容,后缀 (_on) 表示该列代表时间。

其他后缀(甚至前缀)可用于指定数据类型(_at_UTCwhen_ 等)。

具有描述性。保持一致。

I normally name DATETIME columns as ACTION_WORD_on: created_on, completed_on, etc.

The ACTION_WORD defines what the column represents, and the suffix (_on) indicates that the column represents time.

Other suffixes (or even prefixes) may be used to specify the data type (_at, _UTC, when_, etc).

Be descriptive. Be consistent.

只怪假的太真实 2024-08-10 17:09:28

当您不使用 EventIDInt 或 EventEnbaledVarchar 时,为什么将其称为 EventDateTime?为什么在列名中包含数据类型? (我的经验法则是,如果他们正在访问表中的数据,他们最好知道列数据类型是什么,因为否则他们不知道他们正在使用什么。)

这些天我更喜欢我的想法作为描述性列名称,例如:
创建日期
创建日期
创建于
CreatedOn(如果没有时间部分)
AddOn(在语义上可能更合适,具体取决于数据)

选择一个“标签”并在需要该类型数据的每个表中一致地使用它也是一件好事。例如,(几乎)每个表中都有一个“CreateDate”列就可以了,因为这样您将始终知道每个表中的哪一列将告诉您何时创建了行。不要沉迷于“但它们都必须有唯一的名称”的论点;如果您正在编写查询,您最好知道要从哪些表中提取每一列。

--编辑--

我刚刚想起我过去做过的一个例外。如果 DateTime (或 SmallDateTime)列不包含时间部分,只包含日期,作为“提醒”,我会将“Date”放在列名称中,例如“BilledDate”而不是“Billed”或“BilledOn”。这不适用于跟踪添加行的时间,因为您也需要时间。

Why call it EventDateTime, when you don't also use EventIDInt, or EventEnbaledVarchar? Why inlcude the data type in the column name? (My rule of thumb is, if they're accessing data in a table, they better know what the column data types are, 'cause otherwise they don't know what they're working with.)

These days I prefer what I think of as descriptive column names, such as:
CreateDate
DateCreated
CreatedAt
CreatedOn (if there's no time portion)
AddedOn (might be semanitcally more appropriate, depending on the data)

Picking a "label" and using it consistantly in every table that requires that kind data is also a good thing. For example, having a "CreateDate" column in (almost) every table is fine, because then you will always know which column in every table will tell you when a row was created. Don't get hung up with the "but they all have to have unique names" argument; if you're writing a query, you had better know which tables you're pulling each column from.

--Edit--

I just recalled an exception I've done in the past. If a DateTime (or SmallDateTime) column will contain no time portion, just the date, as a "reminder" I'd put "Date" in the column name, such as "BilledDate" instead of "Billed" or "BilledOn". This shouldn't apply when tracking when rows were added, since you'd want the time as well.

强辩 2024-08-10 17:09:28

名称应传达列中数据的业务含义...“DateTime”只是数据的类型。是事件发生的时间吗?什么时候录制的?什么时候存储在数据库中?数据最后一次修改是什么时候?

如果它能有效地传达列所包含内容的含义,那么这个名称就很好。 “日期时间”不好。 “EventDateTime”仅稍好一些。如果表保存事件,则表中的任何日期时间字段都是EventDateTime(它记录与事件相关的一些日期时间)。尽管如果“事件”表中只有一个日期时间列,则 EventDateTime 意味着事件发生的时间,所以这可能没问题。

选择名称,以便它传达值的含义...

给定已编辑的问题,一些建议的名称可能是:

Occurred、OccurredDateTime、OccurredUTC、(或 OccurredLocal),或者,如果事件在您的业务模型中有持续时间,然后可能是 StartedUtc、BeganUtc 或 InitiatedUtc 等。

The name should communicate what Business meaning of the data is in the column... "DateTime" is just the Type of the data. Is it when the event happened? when it was recorded? when it was stored in the DB? When the data was last modified?

If it efficiently communicates the meaning of what the column contains, the name is fine. "DateTime" is not fine. "EventDateTime" is only very slightly better. If the table holds events, then any datetime field in the table is an EventDateTime (It records some datetime related to the event). Although if there's only one datetime column in an "Events" table, then EventDateTime implies that it's when the event happened, so that's probably ok.

Choose or select the name so it communicates the meaning of the value...

Given edited question, some suggested names might be:

Occurred, or OccurredDateTime, or OccurredUTC, (or OccurredLocal), or, if events in your business model have duration, then perhaps StartedUtc, or BeganUtc, or InitiatedUtc, etc.

把人绕傻吧 2024-08-10 17:09:28

我更喜欢以第二种形式创建列——尽管我可能想要一个比 Datetime 更具描述性的名称,具体取决于它的用途。

编辑:在这种情况下,我实际上可能会使用该单个字段的混合,并将其设为“EventDate”、“StartDate”或类似的内容。

I prefer to create columns in the second form--although I'd probably want a more descriptive name than Datetime, depending on what its use would be.

Edit: In this sort of situation, I might actually go with a hybrid for that single field, and make it 'EventDate', 'StartDate', or something similar.

苦行僧 2024-08-10 17:09:28

也许这只是我的看法,但我不认为您应该用数据类型命名列,也不应该在所有字段中复制表名称。

Maybe that's just me, but I don't believe you should name your columns with data types, neither replicate the table name all over the fields.

唯憾梦倾城 2024-08-10 17:09:28

我会避免使用数据类型作为列名(称为 Datetime 的 DATETIME 列),因此我投票支持第一个选项。

I would avoid using datatypes for column names (a DATETIME column called Datetime), so I vote for the first option.

北音执念 2024-08-10 17:09:28

我将列 HappensAt 称为 HappensAt,因为该行描述了事件,而问题中的属性(列)详细描述了事件发生的时间。作为一般规则,我尝试使用单数名词来命名我的表,并使用可用于阅读的短语来命名我的属性,例如

tablename(key) columname columnvalue

所以我可以说

event(131) HappensAt Dec 21, 2009, 21:30

然而这并不是一条不可违反的规则。我仍然会在 BirthDate 列中记录某人的出生日期,而不是在 WasBornOn 列中。当你命名事物时,你必须记住自然语言的常见用法。努力自然使用,其余的就会水到渠成。盲目地遵循规则,你的读者将难以理解。

I'd call the column HappensAt, because the row describe an event and the attribute (column) in question details when it happens. As a general rule I try to name my tables with singular nouns and my attributes with phrases that can be used to read, like

tablename(key) columname columnvalue

So I would then be able to say

event(131) HappensAt Dec 21, 2009, 21:30

However this isn't an inviolable rule. I'd still record the date someone was born in a BirthDate column, not a WasBornOn column. You have to bear in mind the common usages of natural language when you name things. Strive for natural usage and the rest will follow. Follow rules blindly and your readers will struggle for comprehension.

故事与诗 2024-08-10 17:09:28

这里有很多很好的答案,所以我不会重复。但请记住永远不要将列命名为保留字!!!

另外,我真的很喜欢选项 1 中的列名称。

there are many good answers here, so I won't duplicate. But remember don't ever name a column a reserved word!!!

also, I really like the column names in option 1.

荒芜了季节 2024-08-10 17:09:28

我可能会使用类似“WhenRaishedUtc”的内容。

I would likely use something like "WhenRaisedUtc".

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