我们正在使用来自供应商应用程序的数据库设置，该应用程序具有非常难以读取的数据库表名，并且没有关于存储内容的文档。我可以理解为什么人们可能想在专有应用程序中混淆他们的表结构，但这个应用程序（企业资源规划）的卖点之一是它的可定制性。
表名类似于 aptrx（应付帐款交易）和 apmaster_all（奇怪的是，这是供应商表）。这是一个极其复杂的数据库，所以我想知道这个约定是否有任何逻辑，或者它是否只是被有意或无意地混淆了。
据我所知，表名的长度不会显着影响性能，对吗？数据库非常复杂（数百个表），所以排序是有意义的，但我无法想象为什么 AccountsPayableTransactions 不如 aptrx ....
Oracle 长期以来一直限制 30 个字符的表名。我怀疑这是基于原始 16 位环境的遗留问题。
表名的长度可能会对性能产生一些微小的影响，因为所有名称都必须存储在数据字典中，并且还需要解析以进行查询，但我认为您无法衡量命中率。
短表名的一个更重要的影响是它很难使用。我也必须维护一个短名称的企业数据库模式。没有充分的理由使用短表名。易于维护每次都胜过混淆或旧的 DOS 习惯。
我觉得还有两点需要说或阐述：
我总是想花太少时间选择名字，如果我这样做了，以后总是会后悔 - 改变名字很少发生
众所周知的缩写通常比拼写更可取。当缩写为某些人所熟知但还不够多时，我们不再称它为缩写，而是开始称其为代码。
缩略语在有严格限制的平台上可以节省空间，尽管这在现在不如 30 年前重要。（我似乎记得在 1980 年代曾在一个系统上工作过，该系统将您的表名限制为 6 个或 8 个字符。）
缩写通常使表名和列名更易于阅读，只要缩写做得好。如果我整天为 AP 编写代码，我宁愿阅读“ap_trx.inv_num”之类的列名，而不是“accounts_payable_transactions.invoice_number”。（我喜欢下划线。）对于一个好的文本编辑器来说，输入长名称并不是什么大问题。
在会计系统中，“ap”和“trx”都是众所周知的缩写。其他包括“ar”、“gl”和“gj”，用于应收账款、总账和普通日记帐。
在一个设计良好的系统中，如果我在名为“aptrx”的表中找到应付账款交易，我希望在 artrx 中找到应收账款交易，在 gltrx 中找到总账交易等等。我发现“apmaster_all”有点令人费解，但如果我也找到“armaster_all”，我会假设第一个持有所有供应商（与活跃或非活跃供应商相对），第二个同样持有所有客户。
在其他问题域中，您会发现其他众所周知的缩写。在寻址中，您会发现“addr”表示地址、“st”表示街道、“usps”表示美国邮政服务、“ups”表示联合包裹服务、“cty”表示县、“zip”表示区域改进代码等等。
我不会称之为混淆。如果应付账款交易存储在名为“cdrs21”的表中，我称之为混淆。（尽管我曾经为一家公司工作，该公司以这种方式命名所有大型机汇编程序模块。字符限制，而不是混淆。）
但是有用的数据库会增长，当数据库变大时你会遇到问题。当您将问题域添加到数据库时，您会遇到众所周知的缩写相互冲突的情况。如果您与媒体打交道，那么“ap”也可以缩写为“Associated Press”、“alternative press”或“advance placement”。发生这种情况时，是时候放弃缩写或改用代码了。组织越大（数据库越大），我发现代码的频率就越高。
懒惰。IntelliSense 和第 3 方选项使打字成为一个真正难以证明的借口。我宁愿名字有有意义和可读的单词。
只是附和“我的上帝，他们对这个可怕的命名约定无能为力的护目镜”的故事。我上次环境中的数据管理团队表示，使用缩写表名的原因是 DB2 限制（我们在 z/os 和 SQL Server 上使用 DB2）表和列不能超过 18 个字符。我立即指出这与 IBM 网站上的文档不准确。然后他们说这是一个 COBOL 问题（是的，他们正在积极开发 COBOL），以防它需要与数据库对话，然后被 MF 骑师反驳。最后，他们的回应是这是我们的发布标准。
我们请求标准委员会将长度从 18 个字符增加到 32 个字符，并收到 30 个字符的限制。这导致表从“SR_M_DLY_ADV_PRD_S”的无用名称变为“IDX_FDSHRCLAS_LIF_RTRN_STATS_X”FML
因此，在我十几年的经验中，缩短的表名没有提供任何切实的好处，并且会导致更高的开发和维护成本，因为我必须始终参考数据字典来将屏幕上的垃圾转换为有意义的标识符。这可以与我使用过的逻辑命名实体形成对比，并且大部分可以从内存中重新创建，因为它们是直观命名的。
这是一种习惯（我同意凯文斯基的观点）。这是对操作系统（例如 DOS、Windows）和一些不处理这些名称的软件的限制（名称长度、复杂名称单词之间的空格、多语言等）的一些旧问题（可能存在）的反应。有经验的人说：“这样做（使用短名称并用下划线分隔），一切都会好起来的。”
出于上述原因，我喜欢通过海报使用描述性命名。
但还有另一个好处。例如，通过描述性命名，它允许您使用嵌套名称。假设您有一个名为 Employee 的表。如果您与另一个表有关系，则可以将其称为 EmployeeAddress。或员工部门。使用神秘的缩写命名，这几乎是不可能的。
取决于每列的基础定义有多复杂。我认为当人们看到这种描述性很强的列名时，他们会懒惰地使用元数据管理，它们甚至实际上是不完整的描述。您不妨问为什么要缩写任何东西。