Uma vez tive uma mesa e era brilhante e bonita. Ele realizou todas as transações financeiras para uma organização. E então começamos a carregar dados nele.

No mês atual, eles podem declarar e reapresentar valores quantas vezes quiserem. Nos 10 dias finais de um mês, eles reformulavam os números -> executavam o processamento ETL -> revisavam os relatórios várias vezes ao dia. Uma vez que o mês está completo, então os livros são lacrados e não podem modificar valores.

É incrível a quantidade de dados financeiros que uma empresa de serviços financeiros gera... Algo que não percebemos com nosso conjunto de dados de teste era que o volume de dados tornaria seus procedimentos de final de mês insustentáveis. Demorou cada vez mais tempo para excluir os "dados do mês atual" antes de substituí-los pela nova execução de teste.

Tivemos que fazer algo para torná-lo mais rápido para processamento sem quebrar a lista não catalogada de "quem sabe o quê" que tudo depende da tabela MonthlyAllocation. Resolvi bancar o mágico e tirar a toalha de debaixo deles. Eu fui à moda antiga e usei uma Partitioned View . Os dados já tinham um sinalizador IsComplete, então fiz duas tabelas - cada uma com restrições de verificação contrárias: MonthlyAllocationComplete, MonthlyAllocationInComplete

Em seguida, criei a exibição particionada com o mesmo nome da tabela original: MonthlyAllocation. Nenhum processo foi mais sábio sobre a mudança física que fizemos no banco de dados. Nenhum relatório quebrou, nenhum dos analistas com acesso direto relatou problemas com essa "tabela" antes ou depois.

História legal mano, mas aonde você vai?

E se eles tivessem uma convenção de nomenclatura lá, tbl_MonthlyAllocation? O que agora? Gastamos muitas horas de trabalho examinando cada ETL, cada relatório, cada planilha ad-hoc na organização e atualizando-os para usar vw_MonthlyAllocation? E então, é claro, todas essas mudanças passam pelo Conselho de Mudanças e esse é sempre um processo rápido e indolor.

Seu chefe pode perguntar: Qual é a recompensa para a empresa por todo esse trabalho novamente?

A outra opção é deixarmos essa view com o nome tbl_ e não gastar todo esse tempo testando, atualizando e implantando código. O que se torna uma anedota divertida que você explica a todos os novos contratados, e aqueles com pouca atenção, que precisam trabalhar com o banco de dados sobre por que você é inconsistente com a nomeação de objetos

Ou você não codifica objetos com metadados redundantes. O banco de dados lhe dirá alegremente o que é uma tabela, o que é uma visão, o que é uma função com valor de tabela, etc.

As convenções de nomenclatura são boas, apenas não se encurrale com elas.

Brent aqui (o cara que você está se referindo na pergunta).

A razão pela qual eu digo para você não adicionar tbl à frente dos nomes de suas tabelas é a mesma razão pela qual eu diria para não adicionar child à frente do nome do seu filho. Você não os chama de childJohn e childJane. Além de não agregar nenhum valor, eles podem não ser uma criança mais tarde na vida - e seus objetos podem se tornar vistas mais tarde.

Este é um argumento muito subjetivo, mas aqui está minha opinião: o prefixo tbl é inútil.

Quantos cenários você está olhando para o código e não consegue dizer se algo é uma tabela ou outra coisa?

Que valor tbl adiciona, exceto que quando você olha para uma lista de tabelas no Pesquisador de Objetos, você tem que trabalhar mais para encontrar a(s) que está procurando?

Algumas pessoas dizem que querem que fique claro em seu código quando estão lidando com uma tabela ou uma visão. Por quê? E se isso é importante, por que não apenas nomear as visualizações de uma maneira especial? Na maioria dos casos, eles agem exatamente como tabelas, então vejo pouco valor em distinguir.

É uma prática terrível.

tbl
tbl_
Table_
t_

... vi todos eles em produção.

Um dos produtos com os quais estou trabalhando atualmente tem metade das tabelas com o nome tbl_whatever, e a outra metade com o nome "normalmente" - Eles obviamente têm desenvolvedores que estão trabalhando com padrões diferentes. Outro de seus maus hábitos é prefixar nomes de colunas que são chaves estrangeiras com fk, seguido pelo nome da tabela e fkdepois pelo nome da coluna, dando nomes de coluna horríveis como fktbl_AlarmsfkAlarmsID. Essa convenção de nomenclatura é apenas uma extensão lógica de todo o tbl_%mantra, e você pode ver o quão ridículo fica!

Quase me esqueci do outro banco de dados que me faz chorar diariamente. Tipos de dados prefixando nomes de colunas... dtPaymentDate, porque o nome realmente precisava do dtprefixo?`

comDon't verListen prepTo adjThose adjOther nouPeople. proYou auxShould advAlways verUse nouPrefixes prepWith proYour adjTable nouNames. proI auxHave advEven verStarted gerUsing proThem prepIn adjNormal nouWriting.

comSee advHow adjEffective proIt verIs? nouPeople auxCan verUnderstand proYour nouWriting adjBetter!

Usar um prefixo como este é conhecido como notação húngara . Sua premissa é simples: você pode determinar o que é algo pela forma como é nomeado. Isso é particularmente comum em linguagens de programação, especialmente quando os desenvolvedores escrevem funções monolíticas que abrangem dezenas de páginas, seja por falta de habilidade ou falta de recursos da linguagem. É uma ajuda mnemônica que ajuda os desenvolvedores a manter os tipos de dados corretos.

De um modo geral, esse estilo de nomenclatura provavelmente será usado em código realmente antigo, ou por desenvolvedores que estão apenas aprendendo (e por acaso aprenderam esse hábito) ou o fazem desde que se lembram. Em minha experiência, observei que é relativamente raro ver a notação húngara surgir espontaneamente com desenvolvedores inexperientes se eles não forem apresentados a ela por um curso de programação ou tutorial; eles são mais propensos a usar nomes de variáveis ​​como i ou x ou acct .

Além de pintar-se em um canto, isso é realmente apenas preenchimento. A sintaxe SQL é precisa o suficiente para que um desenvolvedor sempre saiba se está falando sobre um campo, registro ou conjunto de dados (que pode ser uma tabela, exibição etc). Embora possa ser um ótimo auxiliar de ensino, essa sintaxe geralmente não deve existir em bancos de dados de produção. Isso pode prejudicar a legibilidade e dificultar a localização da tabela que você está procurando, especialmente se vários temas de nomenclatura alternativos aparecerem, como tbl vs. table vs. tab , etc.

O banco de dados realmente não se importa com o que você chama de suas tabelas, campos, etc. Eles são apenas bytes de dados que são organizados em uma ordem específica por seus operadores humanos ou scripts. No entanto, os humanos que precisam manter esses dados apreciarão nomes significativos, como "usuário", "pedido" e "conta". Também é mais prático se você estiver usando consultas SQL, como "mostrar tabela como 'a%'". O uso de prefixos e sufixos pode complicar desnecessariamente a manutenção trivial.

Eu li algumas postagens de blog como esta ou esta (há algumas) depois que herdei minha primeira instância do SQL Server e notei que muitos objetos eram prefixados, eu queria começar a desenvolver novos com uma abordagem menos detalhada e convenção de nomenclatura singular ( muito mais fácil para mim [ e possivelmente outros desenvolvedores ] trabalhar no Mapeamento Relacional de Objetos).

Um dos prefixos mais usados ​​era Tblou tbl, mas então eu tinha TBLe tbl_e até*TableName*_Tbl

Ao tentar consultar e trabalhar no Visual Studio, isso é um inferno, não importaria ter um conjunto inteiro de tabelas prefixadas tbl, mas mantenha-o assim para todo o banco de dados, pelo menos.

Então, no final, eu definitivamente diria que é uma questão de preferência pessoal, mas também tem muito a ver com consistência e se você seguir esse caminho, muitas pessoas ficarão felizes pelo menos você manter o mesmo ao longo do seu desenvolvimento.

...Por outro lado, eu só queria dizer que, se você adotar outra abordagem e optar por uma tabela sem prefixo e nome singular, você fará um desenvolvedor feliz no futuro, e o que é mais importante do que a felicidade?

Sim, adicionar um prefixo que denota o tipo do objeto é um problema e desnecessário . Porque,

1. Às vezes, os objetos começam a vida como algo, mas acabam se tornando outra coisa . (por exemplo, a tabela tblXxxfoi dividida em tblXxxYe tblXxxZpor algum motivo e substituída por uma visão que une as duas novas tabelas. Agora você tem uma visão chamada tblXxx).
2. Quando você digita tblno editor, seu recurso AutoCompletar trava por 45 segundos e, em seguida, mostra uma lista de 4.000 entradas.

Mas...

Vou bancar o advogado do diabo e dizer algo que outros desaconselharam. Existem alguns casos raros em que um sufixo/prefixo pode ser útil, e aqui está um exemplo da organização para a qual trabalho.

Temos um sistema ERP baseado em entidade, onde a lógica de negócios é escrita em Oracle PL/SQL. Tem quase duas décadas, mas é um sistema muito estável (este não é um sistema legado. Estamos continuamente desenvolvendo-o).

O sistema é baseado em entidade e cada entidade associa uma tabela, várias visualizações, vários pacotes PL/SQL e uma série de outros objetos de banco de dados.

Agora, queremos que os objetos pertencentes à mesma entidade tenham o mesmo nome, mas ainda sejam distinguíveis de sua finalidade e tipo. Então, se tivermos duas entidades nomeadas CustomerOrdere CustomerInvoice, teremos os seguintes objetos:

1. Tabelas para armazenar dados [ TABsufixo]:
   • CUSTOMER_ORDER_TAB
   • CUSTOMER_INVOICE_TAB.
2. Visualizações usadas pelos clientes [Sem sufixo]:
   • CUSTOMER_ORDER
   • CUSTOMER_INVOICE.
3. Interface para operações básicas; (pacotes PL/SQL) [ APIsufixo]:
   • CUSTOMER_ORDER_API
   • CUSTOMER_INVOICE_API.
4. Geradores de relatórios; (pacotes PL/SQL) [ RPIsufixo]:
   • CUSTOMER_ORDER_RPI
   • CUSTOMER_INVOICE_RPI.
5. Índices para chaves primárias [ PKsufixo]:
   • CUSTOMER_ORDER_PK
   • CUSTOMER_INVOICE_PK.
6. Índices secundários [ IXsufixo]:
   • CUSTOMER_ORDER_XXX_IX
   • CUSTOMER_INVOICE_XXX_IX(onde XXXdescreve o uso do índice).
7. ... e assim por diante.

Esta é realmente uma forma de Apps Húngaro (observe que mesmo tipo de objetos podem ter sufixos diferentes dependendo da finalidade). Mas, com um sufixo em vez de um prefixo. Eu não posso dizer o suficiente como este sistema é tão fácil de ler. O IntelliSense realmente funciona porque, em vez de digitar TBLe obter 4.000 resultados, posso digitar Customere obter todos os objetos pertencentes a entidades chamadas Customer*.

Então, aqui eu mostrei como os metadados podem ser úteis. A finalidade é ter um conjunto relacionado de objetos de banco de dados identificáveis ​​por um único nome, mas diferenciá-los com base em sua finalidade .

Dito isto, se você não tem esse tipo de sistema, não há uso de prefixar ou sufixar o tipo de objeto .

Observe que não usamos sufixos como _table, _packageou _view(ou seja, o tipo do objeto). Por exemplo, ambos (3) e (4) são pacotes PL/SQL, mas usam um sufixo diferente. É o mesmo para (5) e (6), ambos índices. Portanto, o sufixo é baseado no propósito e não no tipo .

tl;dr Ele (muito provavelmente) adiciona informações redundantes, levando a sobrecarga cognitiva e, portanto, deve ser removido.

O contexto é uma coisa maravilhosa, especialmente em sistemas de computador. Fora do contexto, você não poderia dizer se algo chamado usersé uma tabela, uma visão, um procedimento armazenado ou algo completamente diferente. Sistemas e linguagens herdados (ou apenas mal escritos) muitas vezes dificultam a compreensão do contexto durante a leitura do código. Por exemplo, no Bash, você não pode dizer o que function usersfaz sem pelo menos ler o conteúdo da função. Em Java, Map<Uid,UserDetails> users()é bastante transparente e você pode acessar os detalhes facilmente.

Levando esse argumento para tabelas SQL, quando seria útil para os consumidores de userssaber se é uma tabela ou uma visão? Em outras palavras, um tblprefixo vai dizer a qualquer um dos consumidores algo que eles não sabem e precisam saber?Esperamos que a grande maioria dos consumidores escreva consultas DML e DQL contra ele. Para eles, deve ser apenas mais uma fonte de dados, e se é uma exibição ou uma tabela deve ser tão relevante quanto se é particionada, armazenada em HDD ou SSD ou qualquer outro detalhe técnico. É claro que o DBA precisa conhecer esses detalhes para executar algumas consultas DDL/DCL raras, mas parece contraproducente poluir o namespace em nome da minoria que realmente sabe como navegar no esquema e obter todos os detalhes técnicos.

One of the features of a relational database management system is that it separates the logical presentation of information to clients from the physical storage. The former is columns in a rowset. The latter is as files on a storage volume. It is the DBMS's job to map one to the other. It is a concern only to the DBA or sysadmin which hardware is supporting the information need. The consumer need not, indeed should not, be aware of those concerns.

Neither should the client be concerned about how a rowset is constructed. A base table, a view or a function are all, in this respect, identical. Each simply produces a set of rows and columns which the client consumes. Even a simple scalar can be considered a one-row, one-column table. The row / column model is the contract between the client and the server.

By prefixing the artefacts' names with their implementation type this separation of concerns is broken. The client is now aware of and dependent on the internals of the server. Change in the server's coding may require client re-work.