使用“type”作为数据库列名

Question

在新数据库表中命名列时，我遇到的一个常见问题是用于分类子类型的正确名称。最自然的列名通常是type，但我尽量避免在命名中使用SQL关键字或保留词。

我知道类型在MySQL和Postgres中都是一个非保留关键字，所以我可以使用它，但是我应该吗？

使用type作为列名的当前最佳实践是什么？是否有一个同义词如此广泛地等价以至于使用它是有意义的？

这些年来，我花了很多时间试图选择其他名字，在过去一周的讨论中，这两次出现，所以我想看看是否有任何明确的共识？

如果它对其他人有帮助，我过去曾使用过一些替代方案来尝试解决这个问题，包括：

< li> 类别 < li> 种类 < li> 子类型 < li> 组 < li> type_of < li> 角色 < li> class < li > <代码>

Answer 1

第一条规则，

永远不要使用关键字或保留词。在你之后的人会受苦。

如果您这次只使用“类型”。您可以使用类型

Answer 2

SQL标准明确promise绝不在任何关键字、保留字等上使用尾随下划线。

因此，如果您使用尾随下划线命名标识符（表名、列名、索引名等），则无需担心冲突。

CREATE TABLE product_ (
    name_ VARCHAR ,
    type_ VARCHAR ,
    …
);

其他人提出的“避免使用保留语”的建议是天真的，可能会失败，而且不可移植。多年前，我对各种数据库产品及其关键字进行了快速调查。我收集了一份大约一千人的独特清单。真正地你不会相信各种产品以各种方式使用了多少不明显的词。当然，冲突是上下文相关的，因此如果您以特定方式使用，并非所有保留字都是问题。但尾随下划线技巧使您无需研究每个产品的保留字列表并监控代码库中潜在的冲突。

命名很棘手。当然，您应该努力使用尽可能清晰的描述性名称。有时，特别是在一个特定的问题领域，像“类型”这样的词可能是合适的。如果是这样，添加尾部下划线(< code>type_)就可以睡个好觉了。

Answer 3

我的建议通常是避免使用关键字，但不是因为它们是保留的，而是因为它们本身往往是模棱两可的。

例如，假设您有一个客户表-带有列“类型”，这可能会填充细分（高价值/低价值等），也可能填充源（直接营销/走进等）。

“类型”是一个低值词。我通常建议以牺牲列长度为代价尽可能明确。例如“CustomerSourceType”或“InventoryLocationType”或任何在场景中实际上更清楚的东西。