Ben*_*cka 22 naming-convention
我们正在使用来自供应商应用程序的数据库设置，该应用程序很难读取数据库表名，并且没有关于存储位置的文档。我可以理解为什么人们可能想要在专有应用程序中混淆他们的表结构，但该应用程序（企业资源规划）的卖点之一是它的可定制性。
表名类似于 aptrx（Accounts Payable Transactions）和 apmaster_all（奇怪的是，这是 vendor 表）。这是一个极其复杂的数据库，所以我想知道这个约定是否有任何逻辑，或者它是否只是被有意或以其他方式混淆。
据我所知，表名的长度不会显着影响性能，对吗？数据库非常复杂（数百个表），所以排序是有道理的，但我无法想象为什么 AccountsPayableTransactions 不如 aptrx ....
kev*_*kio 23
Oracle 长期以来一直限制 30 个字符的表名。我怀疑这是基于原始 16 位环境的遗留问题。
表名的长度可能会对性能产生一些微不足道的影响，因为所有名称都必须存储在数据字典中并解析查询，但我认为您无法衡量命中率。
短表名的一个更重要的影响是它很难使用。我也必须维护一个具有短名称的企业数据库模式。没有充分的理由使用短表名。易于维护每次都胜过混淆或旧的 DOS 习惯。
Jac*_*las 18
我觉得还有两件事需要说或阐述：
计算机科学中只有两个难题：缓存失效和命名事物。菲尔·卡尔顿
我总是倾向于花太少的时间来选择名字，如果我这样做了，以后总是会后悔 - 更改名字的情况很少发生
表名类似于 aptrx（Accounts Payable Transactions）和 apmaster_all（奇怪的是，这是 vendor 表）。这是一个极其复杂的数据库，所以我想知道这个约定是否有任何逻辑，或者它是否只是被有意或以其他方式混淆。
众所周知的缩写通常比拼写出来更可取。当某个缩写为某些人所熟知，但还不够人熟知时，我们就不再称其为缩写，而是开始称其为代码。
缩写可以在有严格限制的平台上节省空间，尽管这在现在不像 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 place”。当这种情况发生时，是时候要么放弃缩写，要么改用代码。组织越大（数据库也越大），我发现代码的频率就越高。