Por que as pessoas recomendam não usar o nome "Id" para uma coluna de identidade?

O prefixo do nome da tabela tem boas razões.

Considerar:

TableA (id int identity, stringdata varchar(max))

TableB (id int identity, stringdata varchar(max))

Queremos DELETEde TableAregistros que existem em ambas as tabelas. Fácil o suficiente, faremos apenas um INNER JOIN:

DELETE a
FROM 
  TableA A
INNER JOIN 
  TableB B
    ON b.id = B.id

.... e acabamos de eliminar tudo TableA. Comparamos inadvertidamente o ID de B com ele mesmo - todos os registros correspondiam e todos os registros eram excluídos.

Se os campos tivessem sido nomeados TableAIde TableBIdisso seria impossível ( Invalid field name TableAid in TableB).

Pessoalmente, não tenho problemas em usar o nome idem uma tabela, mas é realmente uma prática melhor prefaciá-la com o nome da tabela (ou nome da entidade, se TableAfossem pessoas, PeopleIdfuncionaria bem também) para evitar a comparação acidental com o campo errado e explodir algo para cima.

Isso também torna muito óbvio de onde vêm os campos em consultas longas com muitos JOINs.

Principalmente é para evitar que as chaves estrangeiras se tornem uma dor tremenda. Digamos que você tenha duas tabelas: Customer e CustomerAddress. A chave primária para ambos é uma coluna chamada id, que é uma coluna de identidade (int).

Agora você precisa ter o ID do cliente referenciado em CustomerAddress. Você não pode nomear o id da coluna, obviamente, então você vai com customer_id.

Isso leva a alguns problemas. Primeiro, você deve lembrar consistentemente quando chamar a coluna "id" e quando chamá-la de "customer_id". E se você estragar tudo, isso leva ao segundo problema. Se você tiver uma consulta grande com cerca de uma dúzia de junções e ela não retornar nenhum dado, divirta-se jogando Where's Waldo e caçando este erro de digitação:

ON c.id = ca.id

Opa, deveria ter sido ON c.id = ca.customer_id. Ou, melhor ainda, nomeie suas colunas de identidade de forma descritiva, para que possam ser ON c.customer_id = ca.customer_id. Então, se você acidentalmente usar o alias de tabela errado em algum lugar, customer_id não será uma coluna nessa tabela e você obterá um bom erro de compilação, em vez de resultados vazios e subseqüente estrabismo de código.

Concedido, há casos em que isso não ajuda, como se você precisar de vários relacionamentos de chave estrangeira de uma tabela para outra tabela única, mas nomear todas as chaves primárias como "id" também não ajuda.

Aqui está um resumo de todas as respostas sobre as vantagens obtidas com a convenção de não usar um nome comum para todas as chaves primárias:

• Menos erros, já que os campos de identidade não têm o mesmo nome

  Você não pode escrever erroneamente uma consulta que se junta em B.Id = B.Idvez de A.Id = B.Id, porque os campos de identidade nunca serão nomeados exatamente da mesma forma.

• Nomes de colunas mais claros.

  Se você observar uma coluna chamada CustomerId, saberá imediatamente quais dados estão nessa coluna. Se o nome da coluna for algo genérico como Id, você também precisará saber o nome da tabela para saber quais dados a coluna contém.

• Evita aliases de coluna desnecessários

  Agora você pode escrever SELECT CustomerId, ProductIda partir de uma consulta que se junta Customersa Products, em vez deSELECT Customer.Id as CustomerId, Products.Id as ProductId

• Permite a JOIN..USINGsintaxe

  Você pode unir tabelas com a sintaxe Customer JOIN Products USING (CustomerId), em vez deCustomer JOIN Products ON Customer.Id = Products.Id

• A chave é mais fácil de encontrar nas pesquisas

  Se você estiver procurando o campo de identidade de um cliente em uma solução grande, pesquisar CustomerIdé muito mais útil do que pesquisarId

Se você puder pensar em qualquer outra vantagem que essa convenção de nomenclatura tenha, me avise e eu a adicionarei à lista.

A escolha de usar nomes de coluna exclusivos ou idênticos para campos de identidade depende de você, mas independentemente do que você escolher, seja consistente :)

Para copiar minha resposta da pergunta vinculada:

Há uma situação em que colocar "ID" em todas as tabelas não é a melhor ideia: a palavra- USINGchave, se for suportada. Nós o usamos frequentemente no MySQL.

Por exemplo, se você tiver fooTablecom coluna fooTableIde barTablecom chave estrangeira fooTableId, suas consultas poderão ser construídas da seguinte forma:

SELECT fooTableId, fooField1, barField2 FROM fooTable INNER JOIN barTable USING (fooTableId)

Ele não apenas economiza digitação, mas é muito mais legível em comparação com a alternativa:

SELECT fooTable.Id, fooField1, barField2 FROM fooTable INNER JOIN barTable ON (fooTable.Id = barTable.foTableId)

Depois de normalizar um esquema de banco de dados para limitar a redundância, as tabelas são divididas em tabelas menores com relações estabelecidas (um para um, um para muitos, muitos para muitos). No processo, campos únicos na tabela original podem aparecer em várias tabelas normalizadas.

Por exemplo, um banco de dados para um blog pode se parecer com isso em sua forma não normalizada, assumindo uma restrição exclusiva no Author_Nickname.

| Author_Nickname | Author_Email | Post_Title | Post_Body |
+-----------------+--------------+------------+-----------+
| dave            | [email protected]   | Blah       | Bla bla   |
| dave            | [email protected]   | Stuff      | I like    |
| sophie          | [email protected]     | Lorem      | Ipsum     |

A normalização resultaria em duas tabelas:

Autor:

| Author_Nickname | Author_Email |
+-----------------+--------------+
| dave            | [email protected]   |
| sophie          | [email protected]     |

Publicar

| Author_Nickname | Post_Title | Post_Body |
+-----------------+------------+-----------+
| dave            | Blah       | Bla bla   |
| dave            | Stuff      | I like    |
| sophie          | Lorem      | Ipsum     |

Aqui Author_Nickname seria uma chave primária para a tabela author e uma chave estrangeira na tabela post. Mesmo que Author_Nickname apareça em duas tabelas, ele ainda corresponde a uma única unidade de informação, ou seja. cada nome de coluna corresponde a um único campo .

Em muitos casos, não pode haver uma restrição exclusiva nos campos originais, portanto, um campo numérico artificial é usado como chave primária. Isso não muda o fato de que cada nome de coluna ainda representa um único campo. No design de banco de dados tradicional, nomes de colunas individuais correspondem a campos únicos, mesmo que não sejam chaves. (por exemplo, seria possível usar part.partname e client.clientname em vez de part.name e client.name ). Esta é a razão da existência do INNER JOIN ... USING <key>e das NATURAL JOINsintaxes.

No entanto, hoje em dia, e com camadas ORM prontamente disponíveis em muitas linguagens, os bancos de dados são frequentemente projetados como uma camada de persistência para linguagens OO, em que é natural que variáveis ​​que tenham o mesmo papel em diferentes classes sejam chamadas da mesma forma ( part.name e client.name , não part.partname e client.clientname ). Nesse contexto, costumo usar 'ID' para minhas chaves primárias.

Um fornecedor terceirizado que contratamos para criar algo para nós nomeou todas as suas colunas de identidade como Ident apenas para evitar o uso de Id.

Usar "Ident" em vez de "Id" realmente não resolve nada se "Ident" acabar sendo usado em todas as tabelas.

Há um bom artigo sobre convenções de codificação SQL no site Drupal que indica uma boa prática para esta situação:

É uma boa prática prefixar os nomes das tabelas com o nome do módulo para evitar possíveis conflitos de namespace.

Desse ponto de vista, faz sentido usar CustomerProductId e AgencyGroupAssignmentId. Sim, é bastante detalhado. Você poderia encurtá-lo, mas o maior ponto a se preocupar é se o desenvolvedor que o segue entenderá ou não o que você quis dizer . Ids prefaciados com nomes de tabela detalhados não devem deixar ambigüidade quanto ao que são. E (para mim) isso é mais importante do que salvar algumas teclas.

Eu nomeio minhas colunas CustomerID em vez de ID, então sempre que eu digito

FROM dbo.Customers AS c JOIN dbo.CustomerOrders AS o

SQL Prompt sugere imediatamente o seguinte

ON c.CustomerID = o.CustomerID 

Isso me poupa algumas teclas. No entanto, acho que as convenções de nomenclatura são muito subjetivas e, como tal, não tenho uma opinião forte de uma forma ou de outra.

É o mesmo motivo pelo qual você não nomearia todos os seus campos varchar como "UserText" e "UserText1" ou porque não usaria "UserDate" e "UserDate1".

Normalmente, se você tiver um campo de identidade em uma tabela, é sua chave primária. Como você construiria uma tabela filha com uma chave estrangeira para uma tabela pai se a chave primária em ambas as tabelas fosse id?

Nem todo mundo concorda com essa metodologia, mas em meus bancos de dados eu atribuo uma abreviação única a cada tabela. A PK dessa tabela seria denominada PK_[abbrv]ID. SE isso for usado como um FK em qualquer lugar, eu usaria FK_[abbrv]ID. Agora não tenho trabalho de adivinhação para descobrir quais são os relacionamentos da tabela.

Basicamente, pelo mesmo motivo, você normalmente não nomeia os parâmetros parâmetro1, parâmetro2 ... é preciso, mas não descritivo. Se você vir TableId, provavelmente poderá presumir com segurança que ele é usado para armazenar um pk para Table, independentemente do contexto.

Quanto a quem usou Ident, ele perde totalmente o ponto, podendo escolher entre Ident e Id use Id. Ident é ainda mais confuso do que Id.

Fora do contexto, Id pode ser considerado a chave primária para alguma tabela (não é extremamente útil, a menos que o id seja um guid), mas Ident nem mesmo diz isso a você (ou pelo menos a mim). Eu acabaria descobrindo que Ident é a abreviação de identidade (de uma forma ou de outra), mas o tempo que gastei descobrindo isso seria desperdiçado.

Use um prefixo para que o mesmo nome possa ser usado em contextos de chave primária e chave estrangeira, para que você possa executar natural join/ join ... using.