kingdango Asked: 2012-02-18 05:25:55 +0800 CST2012-02-18 05:25:55 +0800 CST 2012-02-18 05:25:55 +0800 CST 我应该使用列命名约定还是依赖列描述？ 772 坦率地说，我很惊讶在一些基本的（非常基本的）互联网搜索之后，我无法找到一个全面的命名约定或指南或 SQL 对象和列命名。 我习惯的类似情况是在 .NET 开发世界中，那里有许多提供的约定，微软甚至记录了一套被广泛采用的综合建议： 一般命名约定 类库开发设计指南 名称准则 1. 数据库对象、列等命名是否有一个被广泛采用的标准？ 2. 依赖Description 属性来描述表的列有什么陷阱吗？显然，人们希望名称能够揭示意图，但这有时在数据库中很难做到，而且描述对于了解数据库的人来说可能是无价的（尽管他们也可能撒谎）。 非常感谢帮助！ naming-convention 4 个回答 Voted Best Answer Aaron Bertrand 2012-02-18T05:34:59+08:002012-02-18T05:34:59+08:00 选择一个标准，确保它有意义，并记录下来。关于这一点有很多争论（例如，联系人表中的身份列是否应该称为 ID 或 ContactID，或者联系人表是否应该称为 dbo.Contacts 或不必要的冗长 dbo.tblContacts），你永远不会会在你的同龄人之间找到共识。你选择哪个标准并不重要；重要的是你始终如一地使用它，让它广为人知，并让你的同事同意这是这种方式。 在可行的情况下，您的专栏应该是自我记录的（而不是神秘的、缩写的或混淆的）。我不会依赖扩展属性，但这只是我（google/bing 用于扩展属性的问题，我猜你会看到很多抱怨）。外部文档/数据字典对我来说更有价值——如果你的数据库南下，你的备份也一样，它会使重建变得容易得多。它还可以更轻松地向初级开发人员等描述您的架构，而无需让他们直接访问所有内容。 onedaywhen 2012-02-18T07:43:03+08:002012-02-18T07:43:03+08:00 数据库对象、列等命名是否有一个被广泛采用的标准？ ISO/IEC 11179 数据元素命名指南。我不确定您所说的“采用良好”是什么意思，但它肯定是全面的，没有过度规范。ISO意味着它被广泛采用。 db2 2012-02-18T05:55:15+08:002012-02-18T05:55:15+08:00 我的建议：根据它们所做或代表的事情来命名事物，而不是它们如何做这些事情。换句话说，不要将表命名为“tblCustomers”，否则您最终可能会得到一个名为“tblCustomers”的向后兼容视图，或者类似的愚蠢行为。同样，不要对列名执行此操作，以免最终从“fltBalance”中获取十进制值。 一个例外是，我偶尔会在视图名称前加上“vw”，以表明它是一个视图，而不是一个表，因此从其中获取数据可能会对性能产生影响。 RGPSoftware 2012-02-18T07:55:20+08:002012-02-18T07:55:20+08:00 就个人而言，我对表和视图使用以下约定： 在表名前加上它所保存的数据类型，这通常很清楚，但并非总是如此。以下是我使用的一些前缀示例： data_（保存核心数据的表） ref_（保存查找值的引用表） xref_（多对多连接表） info_（元数据表（在某些情况下可能不适用，但在我的情况下，像表这样的东西）保存有关数据库使用的关联数据或应用程序的版本等数据）） app_（通过视图附加到其他表的表（同样可能不适用于很多人，但在我的情况下，这些是静态表）包含地理信息等内容，这些信息通过邮政编码等内容附加到记录中） 当然，还有数据仓库中事实和维度广泛使用的 fact_ 和 dim_ 前缀。 有人可能会争辩说，现在应该将这样的前缀实现为模式，但我喜欢为“谁”保留模式，因为它们提供了不同级别的安全管理。 在我目前工作的地方，我们使用所有小写的列名和混合大小写，表名使用下划线分隔符，例如：data_Claim_Transactions。 我们对列名使用所有小写字母，部分原因是我们混合使用了区分大小写的 Java 和 Linux。此外，由于 Oracle 区分大小写，我认为即使您使用的是 SQL Server（默认情况下并非如此），设计区分大小写也是一个好习惯。实际上，我们使用了很长的列名，大约有 100 个字符长，但它们非常具有描述性，并且考虑到我们所做工作的性质，这是必需的。我会说对于应用程序数据库，您可以使用较短的列名。在数据仓库中，您往往需要更长的名称，特别是当您有很多具有相似内容的列或者您有高度非规范化的表时。
选择一个标准，确保它有意义，并记录下来。关于这一点有很多争论（例如，联系人表中的身份列是否应该称为 ID 或 ContactID，或者联系人表是否应该称为 dbo.Contacts 或不必要的冗长 dbo.tblContacts），你永远不会会在你的同龄人之间找到共识。你选择哪个标准并不重要；重要的是你始终如一地使用它，让它广为人知，并让你的同事同意这是这种方式。
在可行的情况下，您的专栏应该是自我记录的（而不是神秘的、缩写的或混淆的）。我不会依赖扩展属性，但这只是我（google/bing 用于扩展属性的问题，我猜你会看到很多抱怨）。外部文档/数据字典对我来说更有价值——如果你的数据库南下，你的备份也一样，它会使重建变得容易得多。它还可以更轻松地向初级开发人员等描述您的架构，而无需让他们直接访问所有内容。
ISO/IEC 11179 数据元素命名指南。我不确定您所说的“采用良好”是什么意思，但它肯定是全面的，没有过度规范。ISO意味着它被广泛采用。
我的建议：根据它们所做或代表的事情来命名事物，而不是它们如何做这些事情。换句话说，不要将表命名为“tblCustomers”，否则您最终可能会得到一个名为“tblCustomers”的向后兼容视图，或者类似的愚蠢行为。同样，不要对列名执行此操作，以免最终从“fltBalance”中获取十进制值。
一个例外是，我偶尔会在视图名称前加上“vw”，以表明它是一个视图，而不是一个表，因此从其中获取数据可能会对性能产生影响。
就个人而言，我对表和视图使用以下约定： 在表名前加上它所保存的数据类型，这通常很清楚，但并非总是如此。以下是我使用的一些前缀示例：
data_（保存核心数据的表） ref_（保存查找值的引用表） xref_（多对多连接表） info_（元数据表（在某些情况下可能不适用，但在我的情况下，像表这样的东西）保存有关数据库使用的关联数据或应用程序的版本等数据）） app_（通过视图附加到其他表的表（同样可能不适用于很多人，但在我的情况下，这些是静态表）包含地理信息等内容，这些信息通过邮政编码等内容附加到记录中）
当然，还有数据仓库中事实和维度广泛使用的 fact_ 和 dim_ 前缀。
有人可能会争辩说，现在应该将这样的前缀实现为模式，但我喜欢为“谁”保留模式，因为它们提供了不同级别的安全管理。
在我目前工作的地方，我们使用所有小写的列名和混合大小写，表名使用下划线分隔符，例如：data_Claim_Transactions。
我们对列名使用所有小写字母，部分原因是我们混合使用了区分大小写的 Java 和 Linux。此外，由于 Oracle 区分大小写，我认为即使您使用的是 SQL Server（默认情况下并非如此），设计区分大小写也是一个好习惯。实际上，我们使用了很长的列名，大约有 100 个字符长，但它们非常具有描述性，并且考虑到我们所做工作的性质，这是必需的。我会说对于应用程序数据库，您可以使用较短的列名。在数据仓库中，您往往需要更长的名称，特别是当您有很多具有相似内容的列或者您有高度非规范化的表时。