在如今的数据化时代，数据对象的命名已经变得越来越重要，如果没有统一的规范和标准，不仅会影响到团队或团队之间信息的传递，更会为企业后续整体跨领域的数据分析带来极大的隐患，值得每一个企业重视。
大家在设计和开发应用产品时要做的第一件事就是数据建模。而数据建模最终落地到数据库就需要设计表、字段等数据对象，而数据对象的命名往往非常关键，尤其对于B端产品，面向的主要是企业端的用户，本身就会自带很多企业及领域的相关知识，字段或表的命名如果不规范、不标准，不仅会影响到团队或团队之间信息的传递，更会为企业后续整体跨领域的数据聚合分析带来极大的隐患。
本文将结合企业的实践分享一些数据对象如表及字段命名的参考建议。而随着企业数据治理方法论的不断完善，数据对象的命名规范与标准，也成为数据治理的重要组成部分，值得每个面向B端产品的团队学习和重视。
命名的目的
在谈命名的建议之前，我们要先搞清楚，我们命名的数据对象的名称，到底是给谁看的？是给计算机看的吗？我们不妨先看看应用程序代码开发的例子，程序员开发编码中一直强调要有优雅的代码结构、准确的变量命名，并为此衍生出设计模式、代码分层、DDD等大量的方法论，难道仅仅是为了让计算机看懂执行吗？我们知道程序员现在使用的是高级编程语言，最终都会被转换成面向机器的二进制指令（类似01010011111这种），所以机器能看懂的最终是这些二进制的指令。
所谓的优雅程序代码结构、准确的变量命名都是给人的看的，是给开发者自己，或者是团队成员看的。是为了能在复杂的业务场景下团队的开发者能够快速的理解代码结构及含义，在保证质量的基础上又能快速的增加新的功能实现，从而提升可测试性、可维护性和可扩展性等。
同理，数据对象中表、字段的名称最终也是要给人看的，给团队里的设计者、开发者、数据分析师等看的。
既然名称最终是给人而且是很多人看的，那么其最重要的作用就是传递信息。所有的命名原则和方法都要围绕着信息传递的最终目标来进行。所以命名的第一原则是直观，在直观的基础上再做到尽量的准确和简洁。我们依次来说明。
1.直观
所谓命名的直观，就是要能做到见名知义，一看到表或字段的名称就知道对应的含义，所以在字段命名时，应该尽量用英文单词全称，除非有业界约定俗成的简称和缩写。比如有一个存储工作流ID的字段，最好的命名就是workflow_id，大家根据英文很快就知道对应的意思了。而有的同学命名会缩写为wf_id，这就要经过额外的人为说明才能够了解对应的含义，显然不是一个很好的命名。
2.准确
命名的准确，就是要准确的反映对象的含义，做到这点并不容易，尤其是B端产品，可能包含了大量的业务术语。举个最简单的例子，比如客户，在英文中有client（客户）、customer（客户，包含最终顾客、消费者等含义）之分，在命名时要根据实际的业务中客户是否有包含终端顾客或消费者来选取准确的单词来表达 。一个简单的客户字段命名要做到准确尚且如此，更不用说发运、发货、收单、收货、保税、含税等这些包含专业领域知识单词的准确命名了。这对完全没有行业背景的人来说简直就是『灾难』。
因此笔者强烈建议：规模较大且面向B端业务的产品开发团队，一定要建立一套公共的命名词典，将经常可能用到的业务术语、词汇总结出来，方便设计开发人员对表、字段、程序变量等对象命名时参考，从而提高命名的效率和准确度。
至于词典中单词的选择，一方面可以学习行业术语，另一方面也可以参考业界标准的B端产品，如企业管理软件就可以参考类似oracle EBS、SAP、salesfore等行业软件的字段命名。
3.简洁
除了直观、准确之外，在命名时还应该做到简洁。毕竟名称过长在使用起来也是有成本的。很多数据库也会会对象名称的长度进行限制，如oracle数据库就规定其包括表、字段等对象的长度不能超过30个字符。所以对于一些业界通用俗成的单词缩写也是可以使用的。比如企业内部的销售订单，虽然完整的英文单词是salesorder，但一般都缩写为so，采购订单缩写为po等。另外对于多个单词组合的情况，为了避免名称过长，也可以适当的缩写。
总 结
总之，在如今的数据化时代，数据对象的命名已经变得越来越重要，如果没有统一的规范和标准，不仅会影响到团队或团队之间信息的传递，更会为企业后续整体跨领域的数据分析带来极大的隐患，值得每一个企业重视。
