Estamos usando uma configuração de banco de dados de um aplicativo de fornecedor que é terrivelmente difícil de ler os nomes das tabelas do banco de dados e nenhuma documentação sobre o que está armazenado e onde. Entendo 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) era sua personalização.
Os nomes das tabelas são como aptrx (Accounts Payable Transactions) e apmaster_all (curiosamente, esta é a tabela vendors). É um banco de dados extremamente complexo, então eu queria saber se havia alguma lógica na convenção ou se estava simplesmente sendo ofuscado intencionalmente ou não.
Pelo que sei, o tamanho do nome da tabela não afetará o desempenho perceptivelmente, correto? O banco de dados é muito complexo (centenas de tabelas), então a classificação faz sentido, mas não consigo imaginar por que AccountsPayableTransactions não é preferível a aptrx....
A Oracle tem um limite de longa data para nomes de tabelas de 30 caracteres. Eu 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 devem ser armazenados em um dicionário de dados e também analisados para consultas, mas não acho que você possa medir o acerto.
Um efeito mais importante de nomes de tabela curtos é que é difícil trabalhar com eles. Eu também tenho que manter um esquema de banco de dados corporativo com nomes curtos. Não há uma boa razão para ter nomes de tabela curtos. A facilidade de manutenção sempre supera a ofuscação ou os velhos hábitos do DOS.
Sinto que há duas coisas que ainda precisam ser ditas ou elaboradas:
Sempre fico tentado a gastar muito pouco tempo escolhendo nomes e sempre me arrependo mais tarde se o fizer - mudar de nome raramente acontece
Abreviações bem conhecidas são geralmente preferíveis a soletrar as coisas. Quando uma abreviação é bem conhecida por algumas pessoas, mas não o suficiente, paramos de chamá-la de abreviação e começamos a chamá-la de código.
As abreviações economizam espaço em plataformas com limites rígidos, embora isso seja menos importante agora do que há 30 anos. (Parece que me lembro de ter trabalhado em um sistema na década de 1980 que limitava você a 6 ou 8 caracteres para um nome de tabela.)
As abreviações geralmente facilitam a leitura dos nomes das tabelas e das colunas, desde que a abreviação seja bem feita. Se eu trabalhasse no código para AP o dia todo, preferiria ler nomes de colunas como "ap_trx.inv_num" do que "accounts_payable_transactions.invoice_number". (Eu gosto de sublinhados.) Digitar nomes longos não é um grande problema com um bom editor de texto.
Nos sistemas de contabilidade, "ap" e "trx" são abreviações bem conhecidas. Outros incluem "ar", "gl" e "gj", para contas a receber, razão geral 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 em artrx, transações de razão geral em gltrx e assim por diante. Acho "apmaster_all" um pouco confuso, mas se 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 mantinha todos os clientes da mesma forma.
Em outros domínios de problemas, você encontra outras abreviações bem conhecidas. No endereçamento, você encontrará abreviações como "addr" para endereço, "st" para rua, "usps" para United States Postal Service, "ups" para United Parcel Service, "cty" para 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 já tenha trabalhado para uma empresa que nomeou todos os seus módulos de montagem de mainframe dessa maneira. Limites de caracteres, não ofuscação.)
Mas os bancos de dados úteis crescem e você se depara com um problema quando os bancos de dados ficam grandes. Ao adicionar domínios de problemas ao seu banco de dados, você se depara com situações em que abreviações conhecidas colidem. Se você lida com a mídia, "ap" também pode abreviar "Associated Press", "imprensa alternativa" ou "colocação avançada". Quando isso acontece, é hora de abandonar as abreviações ou mudar para os códigos. Quanto maior a organização (e quanto maior o banco de dados), mais frequentemente encontro códigos.
Preguiça. IntelliSense e 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.
Apenas concordando com a história de "meu Deus, os óculos não fazem nada para esta horrível convenção de nomenclatura". A equipe de gerenciamento de dados em meu último ambiente afirmou que o motivo para usar nomes de tabelas abreviados era uma limitação do DB2 (tínhamos DB2 em z/os e SQL Server) de 18 caracteres para tabelas e colunas. Eu imediatamente indiquei que isso era impreciso com a documentação do site da IBM. Eles então afirmaram que era um problema de COBOL (sim, eles foram COBOL ativamente desenvolvidos) no caso de precisar falar com o banco de dados que foi então refutado pelos jóqueis do MF. Por fim, a resposta deles foi que é nosso padrão de publicação.
Pedimos ao comitê de padrões para aumentar o comprimento 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
Portanto, em meus cerca de doze anos de experiência, nomes de tabela abreviados não fornecem benefícios tangíveis e resultam em um custo mais alto de desenvolvimento e manutenção, pois devo sempre consultar dicionários de dados para traduzir o lixo na tela para um identificador significativo. O que pode ser contrastado com entidades nomeadas logicamente com as quais trabalhei e que posso recriar principalmente da memória porque foram nomeadas intuitivamente.
É um hábito (concordo com Kevinsky). Foi uma reação a alguns problemas antigos (talvez existam) a restrições (comprimento do nome, espaço entre palavras de nomes complexos, multilíngue etc) do sistema operacional (DOS, Windows, por exemplo) e alguns softwares que não lidavam com esses nomes. Pessoas experientes disseram: "Faça isso (use nomes curtos e separados por sublinhados) e tudo ficará bem."
Eu gosto de usar nomenclatura descritiva pelos motivos mencionados nos pôsteres.
Mas há também outro benefício. Por exemplo, com nomenclatura descritiva, permite usar nomes aninhados. Digamos que você tenha uma tabela chamada Employee. Se você tiver um relacionamento com outra tabela, pode ser chamado de EmployeeAddress. Ou EmployeeDepartment. Com a nomenclatura enigmática e abreviada, 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, na verdade, são descrições incompletas. Você também pode perguntar por que abreviar qualquer coisa.