类词——我最喜欢的数据库列命名约定

原创于 2025-11-20 09:44:02 发布 · 595 阅读

12 ·

CC 4.0 BY-SA版权

License CC BY-NC-SA 4.0 / 自豪地采用谷歌翻译

文章标签：

#榛樿鍒嗙被

榛樿鍒嗙被专栏收录该内容

1105 篇文章

订阅专栏

原文：towardsdatascience.com/classwords-my-favorite-convention-for-naming-database-columns-81cf3093c5a7

在数据工程领域超过二十年的经验中，我发现了一个清晰和一致数据库列的秘密：类词。我这一最喜欢的技巧并不广为人知，但我渴望与您分享其实际益处。让我们深入探讨为什么类词可能是您下一个重要的数据库管理工具。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/d46b7db8ddf8618da1e5582f92309b8c.png

一本优秀的类词书籍 | 图像由 DALL·E 提供

对于我来说，类词不仅仅是命名协议；它们代表了一种清晰的沟通工具，确保每一列的目的和内容都能立即被理解。核心思想很简单：确保每个数据库列的名称能够传达其内部数据的含义。无论是识别特定类型的信息，如日期、文本描述或数值，类词都能使每份数据背后的意图一目了然。

这种约定与您喜欢的任何命名风格都完美结合——驼峰式、帕斯卡式或蛇形 _case。在这篇文章中，虽然我倾向于使用蛇形 _case 因其可读性和流行度，但使用类词的本质超越了这些语法选择。

深入探讨一下，我想分享一些关于应用类词过程的个人反思。每当我需要为一个列名分配类词时，这会迫使我停下来深入思考该列将包含的数据。这些数据真正代表什么？我是否完全理解数据的细微差别？这一刻的反思是无价的。这不仅仅是关于命名；这是确保我和任何其他与这个数据库工作的人都能全面理解其内容。在我的经验中，这种用类词进行深思熟虑的命名实践对于培养更直观和有效的数据管理环境至关重要。

什么是类词？

类词本质上是一些关键词，我们将其附加到数据库列的名称上，以表明它们包含的数据类型。这种约定在数据的形式和功能之间架起了一座桥梁，使任何与数据库互动的人都能立即了解某一列所包含的信息。在本质上，使用类词是在数据库结构中嵌入一层语义清晰度。

类词的美丽之处在于它们的简单性和传达意义的能力。例如，将 _id 添加到列名中表明该列是该实体的唯一标识符。同样，像 _size_kb 这样的后缀告诉你该列存储的是以千字节表示的数据大小信息。这种语义丰富性不仅关乎遵守命名标准，而且关乎将数据库注入一种自解释的品质，这种品质超越了当前团队，并扩展到任何未来的数据工程师或数据分析师。

考虑一个简单地命名为 status 的列。没有额外的上下文或深入数据，很难辨别它所代表的状态的性质。这些是状态代码、状态文本描述，还是表示活动/非活动状态的布尔标志？这种歧义不仅会导致日常操作中的混淆，还可能导致数据分析和报告中的混淆。

通过应用类词，我们可以显著提高清晰度，例如：

status_code – 表示该列包含表示不同状态的数字或符号代码，可能指的是文档中的枚举或查找表。
status_name – 表示该列存储状态的描述性名称，直接在列中提供可读的上下文。

基础类词

让我们更详细地看看每个类别的基类词。

文本类词

文本类词在定义我们数据库中文本数据的性质和功能方面起着至关重要的作用。

identifier（或id） – 这个类词对于唯一性至关重要。它是一个数字或字符字符串，用于标识实体的一个实例（通常是系统生成的，如序列中的数值）；例如，request_id。
code[_<标准>] – 代码是简写表示，通常用于分类。例如，status_code 帮助快速识别状态，而无需存储全名。将此类词扩展为表示所使用的编码标准（如果适用）是一个好习惯。例如，airport_code_iata 明确表示该列存储的是 IATA 机场代码（而非 ICAO 或其他）。
name – 名称简单直接，但对于人类可读识别至关重要。当处理 product_name 时，立即清楚该列存储的是产品名称。
description（或desc） – 描述提供更详细的见解。一个好的做法是确保这些描述既简短又信息丰富，例如 service_description，它可以提供所提供服务的简要概述。
indicator（或ind） – 指示器是表示“是”或“否”/“真”或“假”的标志，例如，is_active_indicator，has_dependencies_indicator。它们通常是布尔值，非常适合快速检查。
number – 尽管名称如此，这里的数字通常不是数学意义上的数值。phone_number 和 serial_number 是很好的例子，其中值用于标识但不用于计算。
text – 当一个词或两个词不足以表达时，comment_text 或 feedback_text 就派上用场，允许使用扩展的字符字符串。

日历类词

日历类词在管理和解释时间数据方面至关重要，为跟踪时间的不同维度提供了一个框架。

date – 当你只需要日历日期时，event_date 会告诉你某事发生的时间，而不必担心确切的时刻。
datetime[_<timezone>]（或 dt[_<timezone>]）— 对于更精确的时间，meeting_start_datetime 可以包括日期和时间，精确到秒。如果使用不传达时区信息的数据类型，请将适当的后缀添加到列名中，以使事情清晰，例如 scheduled_start_dt_utc。
timestamp[_<timezone>]（或 ts[_<timezone>]）— 系统生成，通常包括秒的分数，record_created_timestamp 提供了动作或事件的精确时刻。同样，对于不传达时区信息的数据类型，添加适当的后缀以指示时区，例如 actual_start_ts_utc。

数值类词

数值类词为定量数据带来了秩序和清晰，区分了不同类型的数值信息。无论是计数项目、测量值还是计算比率，这些类词都是准确数据表示和分析的关键。

count – 使用此功能进行项目总计，例如 visitor_count，以衡量参与度或流量。
amount[_<currency>] – 这个类词对于财务数据至关重要。sale_amount_usd 清楚地表明了交易价值以美元计算（货币表示是条件性的*）。
<quantity_property>[_<unit_of_measure>] – 对于可测量的属性，cable_length_meters 不仅指定了长度，还指定了单位（单位表示是条件性的*）。可用于任何类型的可测量属性，如 length、weight、volume、size、distance、duration 等。其他示例包括：file_size_kb、job_duration_seconds、package_weight_kg、avg_speed_mph。
ratio – 比率，如 aspect_ratio，对于没有单位限制的比较至关重要。
factor – 例如 tax_rate_factor 这样的因子提供乘数效应，在计算中非常有用。
percent（或 pct）— 百分比提供了相对度量，如 profit_margin_percent，以普遍理解的方式表示盈利性。然而，最好澄清此值是基于 1 还是 100（即“1”的值是 1% 还是 100%）。
条件性地包含表示货币或度量单位的后缀，取决于是否存在表示货币或度量单位的相关列。如果存在这样的列，则不需要前缀。因此，可以使用 tax_amount_usd 或一对 tax_amount 和 tax_amount_currency_code（如果记录存储的税款金额使用不同的货币）。

特定领域的类词

将特定领域的类词纳入你的命名约定不仅有益，而且是捕捉你特定领域细微差别的基本要求。这些从先前讨论的更一般类词派生出的特化类词，为你的数据架构增加了额外的精确性、命名简化和上下文。

示例：

uri（identifier 类词的特化）- 如 profile_picture_uri 这样的 URI 列存储网络上（甚至现实世界中的）资源的唯一标识符（或地址）。
address（text 类词的特化）- 如果你经常使用类似地址的列，而不是像 postal_address_text 这样称呼它们，引入一个专门的 address 关键字并使用缩写命名：postal_address。
email（address 类词的特化）- 这是命名包含电子邮件地址的列的有用快捷方式。请注意，email 类词也可以是 uri 特化类词的特化。这种来源将表明一个特定于 URI 的电子邮件语法，如 “mailto:[email protected]” 而不是简单的 “[email protected]”。示例包括 customer_service_email（而不是 cutomer_service_email_address 或 customer_service_email_uri）。
sku（code 类词的特化）- 在商业领域，一个有用的特化类词可能是用于库存单位（Stock Keeping Unit），它是库存中每个产品的唯一标识符。例如：product_sku，用于在库存管理系统中识别产品的缩写。
json（text 类词的特化）- 如 config_settings_json 这样的 JSON 列以紧凑的格式存储结构化数据，非常适合配置或数据交换。
geojson（json 类词的特化）- 这可以在 GIS 领域用于以 GeoJSON 格式存储地理数据。例如：parcel_border_geojson，包含表示地块边界的地理空间数据。

注意上下文

在设计表架构时，始终要考虑表本身提供的上下文。例如，在一个名为 product 的表中，给每个列名前加上 product_，如 product_name、product_description 或 product_launch_date，是冗余且不必要的冗长。相反，在这个表中使用简洁的名称，如 name、description 和 launch_date，可以提供所有必要的上下文，而不需要重复的杂乱。下面的查询是否足够易读？

SELECT name, description, launch_date
FROM product

这条规则让我想起了史莱姆命名约定，这是一种编程反模式，关于在命名空间上下文中命名类。但它是命名列在表上下文中的良好类比。

使用类词的关键好处

将类词作为数据库列命名约定的一部分，可以带来许多好处，这些好处可以简化您的数据管理流程并提高数据库模式的可清晰度。以下是为什么我认为类词是我数据库设计工具箱中不可或缺的一部分的原因：

增强可读性和清晰度 – 类词显著提高了数据库列名的可读性和可理解性，最小化了团队成员的学习曲线，并减少了他们对详细文档的依赖。这使得每个人都能在第一眼就掌握每个列的目的和数据类型。
提升 AI 驱动的 SQL 查询生成 – 类词还增强了生成 SQL 查询的 GenAI 模型的准确性。它们帮助 AI 系统更好地理解数据库结构，通过对话界面更容易地提取数据，并使数据库更易于 AI 使用。
与所有基于语法的命名风格兼容 – 类词非常灵活，可以轻松地与任何语法命名模式集成 – camelCase、PascalCase 或 snake_case。这种灵活性意味着采用类词不需要对现有的命名约定进行全面改革，而是通过添加一层语义意义来增强它们。

我希望这次对类词的探讨已经展示了它们在使数据库更易于管理和理解方面的价值。我的经验证明了它们对数据完整性和团队协作的重大影响。我鼓励您考虑将类词纳入您的数据库实践，以实现更清晰和一致的命名约定。

如果您喜欢这篇文章，您可能还会对我的数据库命名约定清单感兴趣。