Por que prefixar nomes de colunas é considerado uma má prática?

De acordo com uma publicação popular do SO, é considerado uma prática ruim prefixar nomes de tabelas. Na minha empresa, cada coluna é prefixada por um nome de tabela. Isso é difícil para mim ler. Não tenho certeza do motivo, mas essa nomeação é realmente o padrão da empresa. Não suporto a convenção de nomenclatura, mas não tenho documentação para fazer backup do meu raciocínio.

Tudo o que sei é que ler o AdventureWorks é muito mais simples. Em esta nossa empresa DB você verá uma tabela, Pessoa e pode ter o nome da coluna:

Person_First_Name
ou talvez até
Person_Person_First_Name (não me pergunte por que você vê a pessoa 2x)

Por que é considerado uma prática ruim pré-corrigir os nomes das colunas? Os sublinhados são considerados maus no SQL também?

Sublinhados não são maus, apenas mais difíceis de digitar. O que é ruim é mudar os padrões no meio do caminho sem consertar todos os objetos existentes. Agora você tem personId, Person_id, etc. e não consegue se lembrar de qual tabela usa sublinhados ou não. A consistência na nomeação (mesmo que você não goste dos nomes) ajuda a facilitar a codificação.

Pessoalmente, o único lugar em que sinto a necessidade de usar o nome da tabela em uma coluna é na coluna ID (o uso de apenas ID é um antipadrão no design de banco de dados, como qualquer pessoa que tenha feito consultas extensas sobre relatórios pode lhe dizer. É muito divertido renomear 12 colunas na sua consulta sempre que você escreve um relatório.) Isso também facilita o conhecimento imediato dos FKs em outras tabelas, pois eles têm o mesmo nome.

No entanto, em um banco de dados maduro, é mais trabalhoso do que vale a pena alterar um padrão existente. Basta aceitar que esse é o padrão e seguir em frente, há coisas muito mais críticas que precisam ser corrigidas primeiro.

Um argumento para a prefixação do nome da coluna evitaria "colisões" de nome ao ingressar em várias tabelas E quando o criador da consulta não usar aliases.

SELECT person.name, company.name FROM person JOIN company ON ...

SELECT * FROM person JOIN company ON ...

Ambas as consultas teriam duas colunas "nome" ( nome_1, nome_2 ) sem "informar" a que entidade pertence. E você nunca pode ter certeza dos nomes das colunas geradas (será name_2 ou name_3 ou ...). Se você usar o nome da tabela prefixação, os nomes das colunas seria PERSON_NAME , company_name para que você saiba cada nome ao qual entidade a que pertence, e você sabe que os nomes das colunas permanecerá constante (se você está recebendo-os em Java usando JDBC, por exemplo, )

Ambos os argumentos podem ser ignorados se você usar alias, mas acho que a maioria das convenções de codificação aplicadas nas empresas é uma consequência de muitos programadores (juniores) que não seguem boas práticas. Nesse caso, por exemplo, o uso do curinga em uma instrução SELECT pode causar problemas sem o prefixo do nome.

Quanto ao sublinhado nos nomes de tabelas e colunas, eu o uso extensivamente porque uso apenas letras minúsculas nos nomes e sublinhado como separador. Usar apenas letras minúsculas ajuda a distinguir identificadores das palavras-chave SQL (que eu digito todas em maiúsculas):

SELECT person_name, COUNT(bought_product) FROM bought_products WHERE person_name LIKE 'A%'

Adicionar esse tipo de prefixo aos nomes das colunas tornará a tabela mais difícil de evoluir. Como exemplo: se, eventualmente, você perceber que deseja / precisa alterar o nome da tabela, precisará modificar toda a estrutura da tabela (ou seja, não apenas o nome da tabela, mas o nome de todas as suas colunas). Isso também tornaria mais difícil atualizar os índices da tabela e o código dos clientes que a consultam.

Existem exceções, se usadas criteriosamente (conforme a resposta de Patrick Karcher no seu link) para nomes de colunas comuns (normalmente apenas ID, às vezes Nome) que seriam ambíguos com muita frequência .

Outra prática recomendada é sempre qualificar colunas e objetos em suas consultas. Portanto, os prefixos de coluna se tornam discutíveis e desorganizam seu código.

Compare estes: qual é o mais fácil para os olhos?

SELECT P.name, P.Salary FROM dbo.Person P

SELECT Person.Name, Person.Salary FROM dbo.Person Person

SELECT dbo.Person.name, dbo.Person.Salary FROM dbo.Person

SELECT Person.Person_name, Person.Person_Salary FROM dbo.Person Person

Em geral, realmente não parece haver nenhum padrão onipresente. A pergunta à qual você se vinculou tem várias respostas votadas com convenções totalmente diferentes. É claro que todos defenderão seus próprios padrões e é muito mais importante manter convenções consistentes em um projeto.

Dito isto, prefixar nomes de colunas parece ser um exagero. Você já sabe em qual tabela está trabalhando e uma situação com duas colunas de tabelas diferentes com o mesmo nome pode ser facilmente resolvida usando aliases de tabela ou coluna.

No TSQL, você pode consultar os campos no formato TableName.FieldName, se desejar evitar ambigüidades, portanto, adicionar nomes de tabelas aos nomes de campos diminui a legibilidade, tornando-os TableName.TableName_FieldName ou similares. Eu acho que usar sublinhados ou não é mais uma escolha pessoal. Eu prefiro o CamelCase e uso _ quando eu quiser adicionar um sufixo ou similar, por exemplo, TableName_Temp, mas isso é só comigo.

Certa vez, trabalhei em um sistema em que decidimos usar códigos curtos para prefixar as colunas. Os campos PK usavam o "nome completo da tabela" como prefixo e todas as outras colunas usavam de 2 a 4 caracteres consistentemente como prefixo. Cada coluna também usou um domínio de dados como sufixo. Se feito de forma consistente, pode ser muito agradável e limpo. Não faz sentido que um padrão de nomenclatura de um tipo ou outro implique codificação desleixada. A presença de um padrão consistente é o que é importante. Eu já vi vários bancos de dados inconsistentes porque não há um padrão claro e que mais do que qualquer outra coisa me indicaria que pode haver problemas nas estruturas de dados. Se o designer de um banco de dados não puder nem mesmo nomear objetos de forma consistente e seus filhos,

Prefixar é uma prática ruim porque causa o problema que foi projetado para evitar. Como você afirmou, é muito difícil ler colunas prefixadas. Se você terminar com nomes de colunas duplicados em uma consulta na qual você une duas tabelas, poderá resolvê-las, ou é uma visão, procedimento armazenado ou função tabular definida pelo usuário que faz isso por você, se você estiver constantemente juntando tabelas específicas.

Tanto quanto usar sublinhado em um nome de tabela, esse é um argumento religioso. No final, aumenta a visibilidade e facilita as coisas. Eu geralmente nunca teria espaços ou tabelas em um nome de coluna ou tabela. No entanto, posso abrir uma exceção para tabelas ou visualizações que foram usadas apenas por um pacote de relatórios ou exportadas para um arquivo CSV.

Muitos bancos de dados têm limites estritos no número de caracteres no nome de uma coluna (ou seja, Oracle).

Se você estiver trabalhando com um banco de dados que permita nomes longos de colunas, mas depois decidir que deseja migrar essa estrutura para outro sistema de banco de dados, os prefixos aumentarão as chances de os nomes de suas colunas serem inválidos.

Embora você esteja trabalhando com o SQL Server agora, ninguém pode prever o futuro, e é possível que seu software precise trabalhar em vários bancos de dados no futuro.

Considere escrever um dicionário de dados (ou "registro"). Por isso, quero dizer um documento contendo todos os elementos de dados em seu modelo: nome, descrição etc. Ele deve ser independente da implementação do modelo, por exemplo, não deve mencionar nomes de tabelas. Como você desambiguaria nomes como 'ID', 'Tipo' e 'Código'?

Uma abordagem é seguir as diretrizes da norma internacional ISO / IEC 11179 - afinal, por que reinventar a roda? A estrutura básica é:

[Object] [Qualifier] Property RepresentationTerm

com delimitadores entre os elementos: o SQL não funciona bem com espaços nos nomes das colunas e o sublinhado funciona bem visualmente.

Sinto que alguém da sua organização estava tentando seguir essas diretrizes quando criaram nomes de elementos como Person_Person_First_Name.

O exemplo que eu gosto de mostrar é o dicionário de dados do Serviço Nacional de Saúde das Nações Unidas (NHS) .

Portanto, não acho que a convenção de nomenclatura com a qual você tenha que trabalhar seja muito ruim.

Na implementação, por exemplo, no SQL, algumas pessoas gostam de omitir os subelementos Objeto, Qualificador e Propriedade quando o nome da tabela fornece contexto, por exemplo, person_first_namefica first_namena Persontabela etc. No entanto, a regra geral de que um elemento de dados não deve mudar seu nome simplesmente devido à sua localização no modelo físico parece ser bom. Qualquer pessoa que ache que não é uma boa ideia seguir esta regra deve ter a tarefa de documentar todas as variações de nome que eles usaram :)

Você encontrará um bom resumo da ISO 11179 no livro Estilo de programação de Joe Celko , incluindo evidências de preferência por sublinhados como delimitadores nos nomes das colunas.

Alguns acham mais fácil no código saber de que tabela os dados vieram; no entanto, se você estiver falando de um sistema orientado a objetos, deverá usar o contexto do nome para saber de onde eles vêm;

Pessoalmente, a prefixação do nome da tabela é uma indicação de que os desenvolvedores não são muito habilidosos e, à medida que você avança, você encontrará muitas outras convenções ruins de codificação e se eu tivesse que adivinhar que o aplicativo tem muitas tabelas, é buggy etc.