Existe um motivo para usar nomes de tabela extremamente abreviados?

Estamos usando uma configuração de banco de dados do aplicativo de um fornecedor que dificilmente lê os nomes das tabelas de banco de dados e não há documentação sobre o que está armazenado onde. Eu posso ver por que alguém pode querer ofuscar sua estrutura de tabela em um aplicativo proprietário, mas um dos pontos de venda desse aplicativo (Enterprise Resource Planning) foi a capacidade de personalização.

Os nomes das tabelas são como aptrx (transações de contas a pagar) e apmaster_all (curiosamente, esta é a tabela de fornecedores). É um banco de dados extremamente complexo, então eu queria saber se havia alguma lógica na convenção ou se ela estava sendo ofuscada intencionalmente ou não.

Que eu saiba, o comprimento do nome da tabela não afetará o desempenho visivelmente, correto? O banco de dados é muito complexo (centenas de tabelas), portanto, a classificação faz sentido, mas não consigo imaginar por que AccountsPayableTransactions não é preferível ao aptrx ....

A Oracle tem um limite de longa data em nomes de tabelas de 30 caracteres. Suspeito que este seja um problema herdado baseado em um ambiente original de 16 bits.
O comprimento de um nome de tabela pode ter algum efeito minúsculo no desempenho, pois todos os nomes precisam ser armazenados em um dicionário de dados e também analisados ​​para consultas, mas não acho que você possa medir a ocorrência.

Um efeito mais importante dos nomes curtos das tabelas é que é difícil trabalhar com elas. Eu também tenho que manter um esquema de banco de dados corporativo com nomes abreviados. Não há um bom motivo para ter nomes curtos de tabela. A facilidade de manutenção supera a ofuscação ou os velhos hábitos do DOS sempre.

Eu sinto que há duas coisas que ainda precisam ser ditas ou elaboradas:

1. Nomear coisas não é tão trivial quanto parece

   Existem apenas dois problemas difíceis na Ciência da Computação: invalidação de cache e nomeação de coisas. Phil Karlton

2. Embora nomes curtos e sem sentido sejam sempre ruins, nomes longos nem sempre são bons - nossos cérebros têm um limiar interno embutido , que é surpreendentemente baixo. Normalmente, 30 caracteres são suficientes, mas eu prefiro o RDBMS para permitir mais casos excepcionais quando não é (e, assim como no idioma, nomes mais longos são mais úteis para coisas sobre as quais não falamos com tanta frequência - como nomes de restrições e nomes mais curtos são mais úteis para tabelas que consultamos o tempo todo)

Fico sempre tentado a gastar muito pouco tempo escolhendo nomes e sempre me arrependo depois, se o fizer - a mudança de nomes acontece apenas raramente

Preguiça. O IntelliSense e as opções de terceiros tornam a digitação uma desculpa muito difícil de justificar. Prefiro que os nomes tenham palavras significativas e legíveis.

Os nomes das tabelas são como aptrx (transações de contas a pagar) e apmaster_all (curiosamente, esta é a tabela de fornecedores). É um banco de dados extremamente complexo, então eu queria saber se havia alguma lógica na convenção ou se ela estava sendo ofuscada intencionalmente ou não.

Abreviaturas conhecidas são geralmente preferíveis a esclarecer as coisas. Quando uma abreviação é conhecida por algumas pessoas, mas não por pessoas suficientes, paramos de chamá-la de abreviação e começamos a chamá-la de código.

Abreviações economizam espaço em plataformas que têm limites rígidos, embora isso seja menos importante agora do que há 30 anos. (Eu me lembro de ter trabalhado em um sistema na década de 1980 que o limitava a 6 ou 8 caracteres para o nome de uma tabela.)

As abreviações geralmente facilitam a leitura dos nomes de tabelas e colunas, desde que a abreviação seja bem-sucedida. Se eu trabalhasse no código do AP o dia inteiro, preferiria ler nomes de colunas como "ap_trx.inv_num" a "accounts_payable_transactions.invoice_number". (Gosto de sublinhados.) Digitar nomes longos não é um problema para um bom editor de texto.

Nos sistemas contábeis, "ap" e "trx" são abreviações conhecidas. Outros incluem "ar", "gl" e "gj", para contas a receber, contabilidade e diário geral.

Em um sistema bem projetado, se eu encontrasse transações de contas a pagar em uma tabela chamada "aptrx", esperaria encontrar transações de contas a receber no artrx, transações de contabilidade geral no gltrx e assim por diante. Acho "apmaster_all" um pouco intrigante, mas se eu também encontrasse "armaster_all", presumiria que o primeiro continha todos os fornecedores (em oposição aos fornecedores ativos ou inativos), e que o segundo continha todos os clientes da mesma forma.

Em outros domínios problemáticos, você encontra outras abreviações conhecidas. Ao endereçar, você encontrará abreviações como "addr" para endereço, "st" para rua, "usps" para o Serviço Postal dos Estados Unidos, "ups" para o United Parcel Service, "cty" para o condado, "zip" para Melhoria de Zona Código e assim por diante.

Eu não chamaria isso de ofuscação. Se as transações de contas a pagar fossem armazenadas em uma tabela chamada "cdrs21", eu chamaria isso de ofuscação. (Embora eu tenha trabalhado uma vez para uma empresa que nomeou todos os módulos montadores de mainframe dessa maneira. Limites de caracteres, não ofuscação.)

Porém, bancos de dados úteis crescem e você enfrenta um problema quando os bancos de dados ficam grandes. À medida que você adiciona domínios problemáticos ao seu banco de dados, você se depara com situações nas quais abreviações conhecidas colidem. Se você lida com a mídia, "ap" também pode abreviar "Associated Press", "Alternative Press" ou "Adiantamento". Quando isso acontece, é hora de abandonar as abreviações ou mudar para códigos. Quanto maior a organização (e maior o banco de dados), mais frequentemente encontro códigos.

Apenas conversando com "meu deus, os óculos não fazem nada por esta horrível convenção de nomes". A equipe de gerenciamento de dados em meu último ambiente declarou que o motivo do uso de nomes de tabelas abreviados era uma limitação do DB2 (tivemos o DB2 no z / os e SQL Server) de 18 caracteres para tabelas e colunas. Eu indiquei prontamente que isso era impreciso na documentação do site da IBM. Eles então declararam que era um problema do COBOL (sim, eles foram ativamente desenvolvidos para o COBOL), caso fosse necessário conversar com o banco de dados que então foi refutado pelos jóqueis do MF. Finalmente, a resposta deles foi o nosso padrão de publicação.

Solicitamos ao comitê de padrões que aumentasse o tamanho de 18 para 32 caracteres e recebemos uma limitação de 30 caracteres. Isso resultou em tabelas passando de nomes inúteis de 'SR_M_DLY_ADV_PRD_S' para 'IDX_FDSHRCLAS_LIF_RTRN_STATS_X' FML

Assim, em minha dúzia de anos de experiência, os nomes abreviados das tabelas não fornecem benefícios tangíveis e resultam em um custo mais alto de desenvolvimento e manutenção, pois sempre devo me referir aos dicionários de dados para traduzir o lixo na tela em um identificador significativo. O que pode ser contrastado com as entidades nomeadas logicamente com as quais trabalhei e pode ser recriado principalmente a partir da memória, porque foram nomeadas intuitivamente.

É um hábito (eu concordo com Kevinsky). Foi a reação de alguns problemas antigos (talvez existam) à restrição (comprimento do nome, espaço entre palavras de nomes complexos, multilíngüe etc.) do sistema operacional (DOS, Windows, por exemplo) e algum software que não lidava com esses nomes. Pessoas experientes disseram: "Faça isso (use nomes curtos e separados com sublinhados) e tudo ficaria bem".

Gosto de usar nomes descritivos pelos motivos acima mencionados em pôsteres.

Mas há também outro benefício. Por exemplo, com nomeação descritiva, permite usar nomes aninhados. Digamos que você tenha uma tabela chamada Funcionário. Se você tem um relacionamento com outra tabela, pode ser chamado de EmployeeAddress. Ou EmployeeDepartment. Com o nome abreviado e enigmático, isso é quase impossível.

Depende de quão complexas são as definições subjacentes de cada coluna. Acho que as pessoas ficam preguiçosas com o gerenciamento de metadados quando veem esse tipo de nome de coluna muito descritivo e até são na verdade descrições incompletas. Você também pode perguntar por que abreviar alguma coisa.