Nomenclatura de colunas de ID em tabelas de banco de dados

Eu queria saber a opinião das pessoas sobre a nomenclatura de colunas de ID em tabelas de banco de dados.

Se eu tiver uma tabela chamada Faturas com uma chave primária de uma coluna de identidade, eu chamaria essa coluna de InvoiceID para não entrar em conflito com outras tabelas e é óbvio o que é.

Onde estou trabalhando atualmente, eles chamaram todas as colunas de ID de ID.

Então, eles fariam o seguinte:

Select  
    i.ID 
,   il.ID 
From
    Invoices i
    Left Join InvoiceLines il
        on i.ID = il.InvoiceID

Agora, vejo alguns problemas aqui:
1. Você precisaria criar um alias para as colunas no select
2. ID = InvoiceID não cabe em meu cérebro
3. Se você não criou um alias para as tabelas e se referiu a InvoiceID, é óbvio que tabela está ligado?

Quais são os pensamentos de outras pessoas sobre o assunto?

ID é um antipadrão SQL. Consulte http://www.amazon.com/s/ref=nb_sb_ss_i_1_5?url=search-alias%3Dstripbooks&field-keywords=sql+antipatterns&sprefix=sql+a

Se você tem muitas tabelas com ID como o id, você está tornando o relatório muito mais difícil. Ele obscurece o significado e torna as consultas complexas mais difíceis de ler, além de exigir que você use aliases para diferenciar no próprio relatório.

Além disso, se alguém for tolo o suficiente para usar uma junção natural em um banco de dados onde ele está disponível, você juntará os registros errados.

Se você gostaria de usar a sintaxe USING que alguns dbs permitem, você não pode se usar ID.

Se você usar ID, pode facilmente acabar com uma junção incorreta se acontecer de estar copiando a sintaxe de junção (não me diga que ninguém nunca faz isso!) E se esqueça de alterar o alias na condição de junção.

Então agora você tem

select t1.field1, t2.field2, t3.field3
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t1.id = t3.table2id

quando você quis dizer

select t1.field1, t2.field2, t3.field3 
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t2.id = t3.table2id

Se você usar tablenameID como o campo de id, esse tipo de erro acidental é muito menos provável de acontecer e muito mais fácil de encontrar.

Sempre preferi ID a TableName + ID para a coluna id e, a seguir, TableName + ID para uma chave estrangeira. Dessa forma, todas as tabelas têm o mesmo nome para o campo id e não há uma descrição redundante. Isso parece mais simples para mim porque todas as tabelas têm o mesmo nome de campo de chave primária.

Quanto a juntar tabelas e não saber qual campo de Id pertence a qual tabela, na minha opinião a consulta deve ser escrita para lidar com essa situação. Onde eu trabalho, sempre prefixamos os campos que usamos em uma instrução com o alias de tabela / tabela.

Tem havido uma briga de nerds sobre isso na minha companhia ultimamente. O advento do LINQ tornou o padrão redundante tablename + ID ainda mais obviamente bobo aos meus olhos. Acho que as pessoas mais razoáveis ​​dirão que se você está escrevendo seu SQL à mão de tal maneira que você tem que especificar nomes de tabelas para diferenciar FKs, então não é apenas uma economia na digitação, mas adiciona clareza ao seu SQL para usar apenas o ID em que você pode ver claramente qual é o PK e qual é o FK .

Por exemplo

FROM Employees e LEFT JOIN Customers c ON e.ID = c.EmployeeID

me diz não só que os dois estão ligados, mas qual é o PK e qual é o FK . Já no estilo antigo, você é forçado a olhar ou torcer para que tenham um nome adequado.

Usamos InvoiceID, não ID. Isso torna as consultas mais legíveis - quando você vê IDsozinho, isso pode significar qualquer coisa, especialmente quando você cria um alias para a tabela i.

Eu concordo com Keven e algumas outras pessoas aqui que o PK para uma tabela deve ser simplesmente Id e as chaves estrangeiras listam a OtherTable + Id.

No entanto, desejo acrescentar uma razão que recentemente deu mais peso a este argumento.

Em minha posição atual, estamos empregando a estrutura de entidade usando a geração POCO. Usando a convenção de nomenclatura padrão de Id, o PK permite a herança de uma classe de base poco com validação e tal para tabelas que compartilham um conjunto de nomes de coluna comuns. Usar Tablename + Id como o PK para cada uma dessas tabelas destrói a capacidade de usar uma classe base para elas.

Apenas um pouco para pensar.

Minha preferência também é ID para chave primária e TableNameID para chave estrangeira. Também gosto de ter uma coluna "nome" na maioria das tabelas onde mantenho o identificador legível pelo usuário (ou seja, nome :-)) da entrada. Essa estrutura oferece uma grande flexibilidade na própria aplicação, posso manipular tabelas em massa, da mesma forma. Isso é uma coisa muito poderosa. Normalmente, um software OO é construído sobre o banco de dados, mas o conjunto de ferramentas OO não pode ser aplicado porque o próprio banco de dados não permite isso. Ter as colunas id e name ainda não é muito bom, mas é um passo.

Selecione
i.ID, il.ID em Faturas i Left Join InvoiceLines il on i.ID = il.InvoiceID

Por que não posso fazer isso?

Select  
    Invoices.ID 
,   InvoiceLines.ID 
From
    Invoices
    Left Join InvoiceLines
        on Invoices.ID = InvoiceLines.InvoiceID

Na minha opinião, isso é muito legível e simples. Nomear variáveis ​​como i e il é uma escolha ruim em geral.

Não é realmente importante, você provavelmente encontrará problemas semelhantes em todas as convenções de nomenclatura.

Mas é importante ser consistente para que você não precise olhar as definições da tabela toda vez que escrever uma consulta.

Acabei de começar a trabalhar em um local que usa apenas "ID" (nas tabelas centrais, referenciado por TableNameID em chaves estrangeiras) e já encontrei DOIS problemas de produção causados ​​diretamente por ele.

Em um caso, a consulta usou "... onde ID em (SELECT ID FROM OtherTable ..." em vez de "... where ID em (SELECT TransID FROM OtherTable ...".

Alguém pode dizer honestamente que não teria sido muito mais fácil identificar se nomes completos e consistentes fossem usados ​​onde a instrução errada seria "... onde TransID está (SELECT OtherTableID de OtherTable ..."? Eu não acho tão.

O outro problema ocorre ao refatorar o código. Se você usar uma tabela temporária enquanto anteriormente a consulta saía de uma tabela central, o código antigo é "... dbo.MyFunction (t.ID) ..." e se isso não for alterado, mas "t" agora se refere a um tabela temporária em vez da tabela principal, você nem mesmo obtém um erro - apenas resultados errados.

Se gerar erros desnecessários é uma meta (talvez algumas pessoas não tenham trabalho suficiente?), Então esse tipo de convenção de nomenclatura é ótimo. Caso contrário, uma nomenclatura consistente é o caminho a percorrer.

Por questões de simplicidade, a maioria das pessoas nomeia a coluna na tabela ID. Se ela tiver uma referência de chave estrangeira em outra tabela, eles explicitamente a chamam de InvoiceID (para usar seu exemplo) no caso de junções, você está criando um alias para a tabela de qualquer maneira, então inv.ID explícito ainda é mais simples do que inv.InvoiceID

Eu pessoalmente prefiro (como foi dito acima) o Table.ID para o PK e o TableID para o FK . Mesmo (por favor, não atire em mim) o Microsoft Access recomenda isso.

NO ENTANTO, TAMBÉM sei que algumas ferramentas de geração favorecem o TableID para PK porque tendem a vincular todos os nomes de coluna que contêm 'ID' na palavra, INCLUINDO ID !!!

Até mesmo o designer de consulta faz isso no Microsoft SQL Server (e para cada consulta que você cria, você acaba removendo todos os relacionamentos recém-criados desnecessários em todas as tabelas no ID da coluna)

ASSIM, por mais que meu TOC interno odeie, mantenho a convenção TableID . Vamos lembrar que ele é chamado de Data BASE , pois será a base para muitos e muitos aplicativos que virão. E todas as tecnologias devem se beneficiar de um Esquema bem normalizado com uma descrição clara.

Nem é preciso dizer que EU traço minha linha quando as pessoas começam a usar TableName, TableDescription e outros. Em minha opinião, as convenções devem fazer o seguinte:

• Nome da tabela: Pluralizado. Ex. Funcionários

• Alias ​​da tabela: Nome completo da tabela, singularizado. Ex.

  SELECT Employee.*, eMail.Address
  FROM Employees AS Employee LEFT JOIN eMails as eMail on Employee.eMailID = eMail.eMailID -- I would sure like it to just have the eMail.ID here.... but oh well

[Atualizar]

Além disso, existem algumas postagens válidas neste tópico sobre colunas duplicadas devido ao "tipo de relacionamento" ou função. Exemplo, se uma loja tem um EmployeeID , isso me diz o que devo. Então, às vezes, faço algo como Store.EmployeeID_Manager . Claro que é um pouco maior, mas pelo menos as pessoas não vão enlouquecer tentando encontrar a tabela ManagerID , ou o que EmployeeID está fazendo lá. Quando a consulta for ONDE, eu simplificaria como: SELECT EmployeeID_Manager as ManagerID FROM Store

Vendo isso da perspectiva de um dicionário de dados formal, eu nomearia o elemento de dados invoice_ID. Geralmente, um nome de elemento de dados será único no dicionário de dados e, idealmente, terá o mesmo nome em todo o período, embora às vezes termos de qualificação adicionais possam ser necessários com base no contexto, por exemplo, o elemento de dados nomeado employee_IDpode ser usado duas vezes no organograma e, portanto, qualificado como supervisor_employee_IDe subordinate_employee_IDrespectivamente.

Obviamente, as convenções de nomenclatura são subjetivas e uma questão de estilo. Acho que as diretrizes ISO / IEC 11179 são um ponto de partida útil.

Para o SGBD, vejo as tabelas como coleções de entidades (exceto aquelas que contêm apenas uma linha, por exemplo, tabela cofig, tabela de constantes, etc.), por exemplo, a tabela onde my employee_IDé a chave seria nomeada Personnel. Então, de imediato, a TableNameIDconvenção não funciona para mim.

Já vi o TableName.ID=PK TableNameID=FKestilo usado em modelos de dados grandes e devo dizer que o acho um pouco confuso: prefiro muito mais que o nome de um identificador seja o mesmo, ou seja, não muda o nome com base na tabela em que aparece. Algo a ser observado é o estilo mencionado acima parece ser usado nas lojas que adicionam uma IDENTITYcoluna (auto-incremento) a todas as tabelas, enquanto evitam as chaves naturais e compostas nas chaves estrangeiras. Essas lojas tendem a não ter dicionários de dados formais nem construir a partir de modelos de dados. Novamente, esta é apenas uma questão de estilo e que eu pessoalmente não concordo. Então, no final das contas, não é para mim.

Dito isso, às vezes vejo um caso de descartar o qualificador do nome da coluna quando o nome da tabela fornece um contexto para fazer isso, por exemplo, o elemento nomeado employee_last_namepode se tornar simplesmente last_namena Personneltabela. O raciocínio aqui é que o domínio é 'sobrenomes de pessoas' e é mais provável que seja UNIONeditado com last_namecolunas de outras tabelas em vez de ser usado como uma chave estrangeira em outra tabela, mas, novamente ... Posso apenas mudar de ideia, às vezes você nunca sabe. É isso: modelagem de dados é parte arte, parte ciência.

Acho que você pode usar qualquer coisa para o "ID", desde que seja consistente. Incluir o nome da tabela é importante para. Eu sugeriria o uso de uma ferramenta de modelagem como o Erwin para impor as convenções e padrões de nomenclatura para que, ao escrever consultas, seja fácil entender os relacionamentos que podem existir entre as tabelas.

O que quero dizer com a primeira declaração é que, em vez de ID, você pode usar algo como 'recno'. Portanto, essa tabela teria um PK de invoice_recno e assim por diante.

Saúde, Ben

Meu voto é para InvoiceID para o ID da tabela. Eu também uso a mesma convenção de nomenclatura quando ela é usada como uma chave estrangeira e uso nomes de alias inteligentes nas consultas.

 Select Invoice.InvoiceID, Lines.InvoiceLine, Customer.OrgName
 From Invoices Invoice
 Join InvoiceLines Lines on Lines.InvoiceID = Invoice.InvoiceID
 Join Customers Customer on Customer.CustomerID = Invoice.CustomerID

Claro, é mais longo do que alguns outros exemplos. Mas sorria. Isso é para a posteridade e, algum dia, algum pobre programador júnior terá que alterar sua obra-prima. Neste exemplo, não há ambigüidade e, à medida que tabelas adicionais são adicionadas à consulta, você ficará grato pelo detalhamento.

Para o nome da coluna no banco de dados, eu usaria "InvoiceID".

Se eu copiar os campos em uma estrutura sem nome via LINQ, posso chamá-lo de "ID" lá, se for a única ID na estrutura.

Se a coluna NÃO for usada em uma chave estrangeira, de forma que ela seja usada apenas para identificar exclusivamente uma linha para edição, edição ou exclusão, vou chamá-la de "PK".

Se você der a cada chave um nome exclusivo, por exemplo, "invoices.invoice_id" em vez de "invoices.id", você pode usar os operadores "natural join" e "using" sem preocupações. Por exemplo

SELECT * FROM invoices NATURAL JOIN invoice_lines
SELECT * FROM invoices JOIN invoice_lines USING (invoice_id)

ao invés de

SELECT * from invoices JOIN invoice_lines
    ON invoices.id = invoice_lines.invoice_id

O SQL é detalhado o suficiente sem torná-lo mais detalhado.

O que eu faço para manter as coisas consistentes para mim (onde uma tabela tem uma única chave primária de coluna usada como o ID) é nomear a chave primária da tabela Table_pk. Em qualquer lugar que eu tenha uma chave estrangeira apontando para a chave primária dessa tabela, eu chamo a coluna PrimaryKeyTable_fk. Dessa forma, eu sei que se eu tiver um Customer_pkna minha tabela Customer e um Customer_fkna minha tabela Order, eu sei que a tabela Order está se referindo a uma entrada na tabela Customer.

Para mim, isso faz sentido especialmente para associações, onde acho que é mais fácil.

SELECT * 
FROM Customer AS c
    INNER JOIN Order AS c ON c.Customer_pk = o.Customer_fk

FWIW, nosso novo padrão (que muda, uh, quero dizer "evolui", a cada novo projeto) é:

• Nomes de campos de banco de dados em minúsculas
• Nomes de tabelas em maiúsculas
• Use sublinhados para separar palavras no nome do campo - converta-os para maiúsculas e minúsculas em Pascal no código.
• pk_ prefixo significa chave primária
• _id sufixo significa um número inteiro, ID de auto-incremento
• fk_ prefixo significa chave estrangeira (nenhum sufixo necessário)
• _VW sufixo para visualizações
• is_ prefixo para booleanos

Assim, uma tabela denominada nomes podem ter os campos pk_name_id, first_name, last_name, is_alive,e fk_companye uma vista chamada LIVING_CUSTOMERS_VW, definida como:

SELECT first_name, last_name
DE CONTACT.NAMES
WHERE (is_alive = 'True')

Como outros já disseram, praticamente qualquer esquema funcionará, desde que seja consistente e não ofusque desnecessariamente seus significados.

Eu definitivamente concordo em incluir o nome da tabela no nome do campo ID, exatamente pelos motivos que você forneceu. Geralmente, este é o único campo em que eu incluiria o nome da tabela.

Eu odeio o nome de id simples. Eu prefiro sempre usar o invoice_id ou uma variante dele. Sempre sei qual é a tabela autorizada para o id quando preciso, mas isso me confunde

SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceID = inv.ID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceLineID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceLineID = inv.ID 

O pior de tudo é a mistura que você mencionou, totalmente confusa. Tive que trabalhar com um banco de dados onde quase sempre era foo_id, exceto em um dos ids mais usados. Isso foi um inferno total.

Eu prefiro DomainName || 'EU IRIA'. (ou seja, DomainName + ID)

DomainName é frequentemente, mas nem sempre, igual a TableName.

O problema com o ID por si só é que ele não é escalonado para cima. Depois de ter cerca de 200 tabelas, cada uma com uma primeira coluna chamada ID, os dados começam a parecer todos iguais. Se você sempre qualifica o ID com o nome da tabela, isso ajuda um pouco, mas não muito.

DomainName & ID podem ser usados ​​para nomear chaves estrangeiras, bem como chaves primárias. Quando as chaves foriegn são nomeadas de acordo com a coluna à qual fazem referência, isso pode ser de ajuda mnemônica. Formalmente, amarrar o nome de uma chave estrangeira à chave que ela faz referência não é necessário, uma vez que a restrição de integridade referencial estabelecerá a referência. Mas é extremamente útil quando se trata de ler consultas e atualizações.

Ocasionalmente, DomainName || 'ID' não pode ser usado, porque haveria duas colunas na mesma tabela com o mesmo nome. Exemplo: Employees.EmployeeID e Employees.SupervisorID. Nesses casos, uso RoleName || 'ID', como no exemplo.

Por último, mas não menos importante, eu uso chaves naturais em vez de chaves sintéticas quando possível. Existem situações em que as chaves naturais não estão disponíveis ou não são confiáveis, mas existem muitas situações em que a chave natural é a escolha certa. Nesses casos, deixo a chave natural assumir o nome que teria naturalmente. Esse nome geralmente nem tem as letras 'ID'. Exemplo: OrderNo, onde No é uma abreviatura para "Número".

Para cada tabela, eu escolho uma abreviação de letras de árvore (por exemplo, Funcionários => Emp

Dessa forma, uma chave primária de numeração automática torna-se nkEmp .

É curto, único em todo o banco de dados e conheço exatamente suas propriedades à primeira vista.

Eu mantenho os mesmos nomes em SQL e em todas as linguagens que uso (principalmente C #, Javascript, VB6).

Consulte as convenções de nomenclatura do site Interakt para um sistema bem pensado de nomenclatura de tabelas e colunas. O método usa um sufixo para cada tabela ( _prdpara uma tabela de produtos ou _ctgpara uma tabela de categorias) e o anexa a cada coluna em uma determinada tabela. Portanto, a coluna de identidade para a tabela de produtos seria id_prde, portanto, única no banco de dados.

Eles vão um passo adiante para ajudar a entender as chaves estrangeiras: A chave estrangeira na tabela de produtos que se refere à tabela de categorias seria de idctg_prdforma que seja óbvio a qual tabela ela pertence (_prd sufixo) e a qual tabela ela se refere (categoria) .

As vantagens são que não há ambigüidade com as colunas de identidade em diferentes tabelas e que você pode dizer rapidamente a quais colunas uma consulta está se referindo pelos nomes das colunas.

veja também convenção de nomenclatura de chave primária / chave estrangeira

Você pode usar a seguinte convenção de nomenclatura. Ele tem suas falhas, mas resolve seus problemas particulares.

1. Use apelidos curtos (3-4 caracteres) para os nomes das tabelas, ou seja, Invoice - inv, InvoiceLines -invl
2. Nomeie as colunas na tabela usando esses apelidos, ou seja inv_id,invl_id
3. Para as colunas de referência, use invl_inv_idpara os nomes.

desta forma você poderia dizer

SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id