是否有理由使用极端缩写的表名？

我们正在使用供应商的应用程序中的数据库设置，很难读取数据库表名称，也没有关于存储位置的文档。我可以看到为什么要在专有应用程序中混淆其表结构，但是此应用程序（企业资源计划）的卖点之一是它的可定制性。

表名称就像aptrx（应付帐款交易）和apmaster_all（奇怪的是，这是供应商表）。这是一个非常复杂的数据库，所以我想知道该约定是否有任何逻辑，或者是否只是有意地对其进行了混淆。

据我所知，表名的长度不会明显影响性能，对吗？数据库非常复杂（数百个表），因此排序是有意义的，但是我无法想象为什么AccountsPayableTransactions不如aptrx更好。

Oracle对30个字符的表名有长期的限制。我怀疑这是基于原始16位环境的遗留问题。
表名的长度可能会对性能产生微不足道的影响，因为所有名称都必须存储在数据字典中，并且还要解析查询以进行查询，但是我认为您无法衡量命中率。

短表名的一个更重要的影响是它很难使用。我也必须使用短名称维护企业数据库架构。没有短表名的充分理由。每次维护都容易胜过混淆或过时的DOS习惯。

我觉得还有两件事需要说或加以阐述：

1. 命名事物并不像听起来那么琐碎

   在计算机科学中只有两个棘手的问题：缓存失效和命名。菲尔·卡尔顿

2. 虽然简短的无意义名称总是不好的，而简短的名称却并不总是很好的-我们的大脑有一个内置的tl; dr阈值，这个阈值令人惊讶地低。通常 30个字符就足够了，但是我更喜欢RDBMS在非特殊情况下允许更多（和语言一样，较长的名称对于我们不常谈论的事情更有用-约束名称，以及较短的名称对于我们一直查询的表更有用）

我总是很想花很少的时间来选择名字，如果这样做的话，以后总是会后悔的-改变名字的情况很少发生

懒惰。IntelliSense和3rd party选项使键入成为难解难解的借口。我更希望这些名称具有有意义且易读的词。

表名称就像aptrx（应付帐款交易）和apmaster_all（奇怪的是，这是供应商表）。这是一个非常复杂的数据库，所以我想知道该约定是否有任何逻辑，或者是否只是有意地对其进行了混淆。

众所周知的缩写通常比拼写更合适。当某些人熟知缩写但又没有足够多的缩写时，我们就停止称其为缩写，而开始称其为代码。

缩写词可以节省具有严格限制的平台上的空间，尽管现在它不像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”也可以缩写为“美联社”，“另类报刊”或“预先放置”。发生这种情况时，该放弃缩写或切换到代码了。组织越大（数据库越大），我发现代码的频率就越高。

只要和“我的天哪，护目镜对这个可怕的命名约定什么也没做”相吻合。我在上一个环境中的数据管理团队指出，使用缩写表名的原因是表和列的DB2限制（在z / os和SQL Server上为DB2）限制为18个字符。我及时指出，这与IBM网站上的文档不符。然后，他们说这是一个COBOL问题（是的，他们是积极开发的COBOL），以防需要与数据库进行交谈，然后由MF骑师拒绝了。最后，他们的回应是这是我们的发布标准。

我们请标准委员会将长度从18个字符增加到32个字符，并且限制为30个字符。这导致表从无用的名称“ SR_M_DLY_ADV_PRD_S”变为“ IDX_FDSHRCLASLAS_LIF_RTRN_STATS_X” FML

因此，根据我十几年来的经验，缩短表名并没有带来明显的好处，并且导致更高的开发和维护成本，因为我必须始终参考数据字典来将屏幕上的垃圾转换为有意义的标识符。这与我使用过的逻辑命名的实体形成对比，并且由于它们是直观命名的，因此大多数情况下可以从内存中重新创建。

这是一个习惯（我同意凯文斯基的观点）。这是对操作系统（例如DOS，Windows）和某些无法处理名称的软件的限制（名称长度，复杂名称的单词之间的间隔，多语言等）的某些旧问题（可能存在）的反应。有经验的人说：“这样做（使用简短的名称并用下划线名称分隔），一切都会好的。”

由于海报的上述原因，我喜欢使用描述性命名。

但是还有另一个好处。例如，通过描述性命名，它允许您使用嵌套名称。假设您有一个名为Employee的表。如果您与另一个表有关系，则可以将其称为EmployeeAddress。或EmployeeDepartment。使用隐晦的命名方式，这几乎是不可能的。

取决于每列的基础定义的复杂程度。我认为人们在看到这类描述性很强的列名时就懒于使用元数据管理，实际上它们甚至是不完整的描述。您不妨问一问，为什么要缩写。