Por que nomear a coluna "Chave" da chave primária de uma tabela é considerado uma prática ruim? [fechadas]

210

Meu professor de t-sql nos disse que nomear nossa coluna PK "Id" é considerada uma prática ruim sem maiores explicações.

Por que nomear uma coluna PK da tabela "Id" é considerado uma prática ruim?

Jean-Philippe Leclerc
fonte
27
Bem, na verdade não é uma descrição e Id significa "identidade", o que é muito auto-explicativo. Essa é a minha opinião.
Jean-Philippe Leclerc
49
Tenho certeza de que existem muitas lojas que usam Id como um nome PK. Eu pessoalmente uso o TableId como minha convenção de nomenclatura, mas não diria a ninguém que é A ÚNICA MANEIRA VERDADEIRA. Parece que sua professora está apenas tentando apresentar sua opinião como uma prática recomendada amplamente aceita.
22
Definitivamente, o tipo de má prática que não é tão ruim assim. O objetivo é ser consistente. Se você usa o id, use-o em qualquer lugar ou não.
Deadalnix 17/10
57
Você tem uma tabela ... se chama Pessoas, tem uma coluna, chamada Id, o que você acha que é o Id? Um carro? Um barco? ... não, é o People ID, é isso. Acho que não é uma prática ruim e não é necessário nomear a coluna PK como algo diferente de Id.
jim
38
Então o professor fica na frente da classe e diz que essa é uma prática ruim sem uma única razão? Essa é uma prática pior para um professor.
JeffO 19/10/11

Respostas:

247

Vou dizer: não é realmente uma prática ruim (e mesmo que seja, não é tão ruim assim).

Você pode argumentar (como Chad apontou) que pode mascarar erros como na consulta a seguir:

SELECT * 
    FROM cars car
    JOIN manufacturer mfg
        ON mfg.Id = car.ManufacturerId
    JOIN models mod
        ON mod.Id = car.ModelId
    JOIN colors col
        ON mfg.Id = car.ColorId

mas isso pode ser atenuado facilmente, não usando aliases minúsculos para os nomes de suas tabelas:

SELECT * 
    FROM cars
    JOIN manufacturer
        ON manufacturer.Id = cars.ManufacturerId
    JOIN models
        ON models.Id = cars.ModelId
    JOIN colors
        ON manufacturer.Id = cars.ColorId

A prática de SEMPRE usar abreviações de três letras parece muito pior para mim do que usar o nome da coluna id. (Caso em questão: quem realmente abreviaria o nome da tabela carscom a abreviação car? Que finalidade isso serve?)

O ponto é: seja consistente. Se sua empresa usa o ID e você geralmente cometer o erro acima, adquira o hábito de usar nomes de tabelas completos. Se sua empresa proíbe a coluna Id, aguarde e use a convenção de nomenclatura que preferir.

Concentre-se em aprender coisas que são realmente más práticas (como várias subconsultas correlacionadas aninhadas) em vez de ponderar sobre questões como essa. A questão de nomear suas colunas como "ID" está mais próxima de ser uma questão de gosto do que de uma má prática.


NOTA PARA OS EDITORES: O erro nesta consulta é intencional e está sendo usado para fazer uma observação. Leia a resposta completa antes de editar.

riwalk
fonte
11
@Chad, era uma referência ao fato de que, nessa consulta em particular, você usou três letras para apelidos para nomes de tabelas, mesmo quando não fazia sentido ( cars-> car. Graças a Deus - você salvou meus dedos). Não leia muito profundamente.
riwalk
3
pior do que meus nomes alternativos, foi minha mistura de pluralidade carse manufacturer. Um é plural, o outro não. Se as pessoas querem escolher o banco de dados, essa é a má prática a ser adotada.
CaffGeek 17/10
3
Eu acho que é uma prática ruim. Obviamente, no que diz respeito às más práticas, não é terrível ... mas é tão fácil evitar, por que não fazê-lo? Agora, eu concordo, para uma aula de introdução, é isso que deve ser focado? Provavelmente não .... #
42623
2
@ user606723, na verdade, acho que para uma aula de introdução é importante ressaltar. Ensinar as melhores práticas deve ser fundamental. Não é até você ter experiência que você entende as conseqüências, as compensações e quando deve se desviar das melhores práticas.
CaffGeek 17/10
5
@ Chade, concordo em discordar. Tentar ensinar aos alunos as "melhores práticas" sem permitir que eles entendam por que essas são as melhores práticas é um esforço inútil. E como você não pode cobrir tudo, encobrir esse ponto com "você simplesmente não deve fazê-lo, descobrirá o porquê depois" é uma escolha bastante sensata do ponto de vista de um professor. Os alunos curiosos podem postar aqui ou, espero, encontrar essa pergunta já respondida. (Ou pergunte depois da aula)
user606723
123

Porque quando você tem uma tabela com uma chave estrangeira, não pode nomear essa chave estrangeira "Id". Você tem o nome da tabela TableId

E então sua junção parece

SELECT * FROM cars c JOIN manufacturer m ON m.Id = c.ManufacturerId

E, idealmente, sua condição deve ter o mesmo nome de campo em cada lado

SELECT * FROM cars c JOIN manufacturer m ON m.ManufacturerId = c.ManufacturerId

Portanto, embora pareça redundante nomear o ID como ManufacturerId, é menos provável que você tenha erros nas condições de junção, à medida que os erros se tornam óbvios.

Parece simples, mas quando você junta várias tabelas, é mais provável que você cometa um erro, encontre a tabela abaixo ...

SELECT * 
    FROM cars car 
    JOIN manufacturer mfg
        ON mfg.Id = car.ManufacturerId
    JOIN models mod
        ON mod.Id = car.ModelId
    JOIN colors col
        ON mfg.Id = car.ColorId

Considerando que, com a nomeação adequada, o erro se destaca ...

SELECT * 
    FROM cars car 
    JOIN manufacturer mfg
        ON mfg.ManufacturerId = car.ManufacturerId
    JOIN models mod
        ON mod.ModelId = car.ModelId
    JOIN colors col
        ON mfg.ManufacturerId = car.ColorId

Outro motivo para nomear o ID como "ruim" é que, quando você está consultando informações de várias tabelas, precisará renomear as colunas do Id para poder distingui-las.

SELECT   manufacturer.Id as 'ManufacturerId'
        ,cars.Id as 'CarId'
        --etc
    FROM cars 
    JOIN manufacturer
        ON manufacturer.Id = cars.Id

Com nomes precisos, isso é menos problemático

CaffGeek
fonte
174
Não tenho certeza se esta é uma explicação boa o suficiente para mim. Não há nada de errado em dizer SELECT * FROM cars c JOIN manufacturer m ON manufacturer.Id = c.ManufacturerId. Eu uso idhá anos e nunca achei o que você descreveu como um problema real.
riwalk
61
Eu diria que a má prática aqui é aliasar tabelas com nomes como mfg ou mod. manufacturer.id = cars.manufacturer_id é muito legível e o erro também ocorre.
Deadalnix 17/10/11
5
@Chad> Eu já tenho problemas com nomes de variáveis ​​idiotas. Muitas vezes. Para o registro, aqui o que eu diria a um desenvolvedor que faz isso na minha equipe «mfg não significa fabricante, significa que você é preguiçoso ao digitar fabricante».
Deadalnix 17/10/11
9
@ Stargazer712: Fazer SELECT * de 2 tabelas fornece 2 x colunas de identificação. O ID agora é ambíguo: você faz referência por ordinal ou nome? SELECT * também não é uma boa prática. Argumentos ruins. Código frágil. Chade está correto: codificação defensiva basicamente
gbn 17/10
6
@gbn, novamente, toda a ambiguidade se foi, se você simplesmente faz SELECT manufacturer.id FROM .... Toda dificuldade resultante idpode ser superada com muita facilidade, tornando-a simplesmente uma questão de gosto.
riwalk
67

A biblioteca ActiveRecord do Ruby e o GORM do Groovy usam "id" para a chave substituta por padrão. Eu gosto dessa prática. Duplicar o nome da tabela em cada nome de coluna é redundante, tedioso para escrever e mais tedioso para ler.

kevin cline
fonte
30
+1 em "e mais tedioso para ler". - as convenções de nomenclatura não devem ser pensadas como um band-aid para códigos desleixados, devem melhorar a legibilidade como uma preocupação principal.
ocodo 18/10/11
12
ID é muito mais tedioso para ler
HLGEM
5
@HLGEM: Sempre é possível qualificar o nome da coluna com o nome da tabela.
Kevin cline #
2
Eu concordaria, exceto pelos mais entediantes de ler. Na verdade, prefiro ler nomes de colunas mais descritivos e gastar menos tempo descobrindo para que serve realmente essa coluna.
Devin Dixon
2
+1, Odeio ver tabelas com colunas como Posts.postID, Posts.postName, onde o simples uso de post.id e post.name é muito mais bonito.
Doug
40

Nomes de colunas comuns ou de chave como "Nome" ou "Id" devem ser prefixados com o Nome da Tabela.

Ele remove a ambiguidade, mais fácil de procurar, significa muito menos aliases da coluna quando os dois valores de "ID" são necessários.

Uma coluna menos usada ou de auditoria ou sem chave (por exemplo, LastUpdatedDateTime) não importa

gbn
fonte
57
Se você fizer isso, eu odeio você por me fazer digitar extra !!!! O nome da tabela é Pessoa, qual você acha que o ID será? Carro? não, é pessoa.
jim
16
@ Jim, eu não sei sobre você, mas digitar 6 caracteres extras me leva aproximadamente meio segundo. E considerando que eu raramente seleciono uma tabela e, portanto, terminaria com duas colunas denominadas 'Id' e precisará incluir o nome da tabela / alias de qualquer maneira, não há economia no número de caracteres digitados.
CaffGeek 17/10
21
@ Chad acho supérfluo. se estou fazendo uma junção, c.id = m.manufacturerid, está bem comigo. Essas colunas geralmente são "mapeadas" para uma classe de alguma forma, e ter uma classe com Person.PersonId me faz querer vomitar ... Sim, eu tenho plena consciência de que tenho problemas.
jim
20
Eu também discordo disso. Por que parar em namee id? Por que não ter todas as colunas prefixadas com o nome da tabela? Parece arbitrário escolher esses dois nomes para determinar um prefixo. Conceitualmente, você deve ter a tabela para ter o contexto de uma coluna de qualquer maneira. Por que não usar esse nome tabela para esclarecer a consulta: Person.Name, Animal.Name, Part.Name, ...
Thomas
11
@ Bill Leeper, DRY nem sempre é apropriado no desenvolvimento de banco de dados. Nos bancos de dados, o importante é desempenho e fazer com que o banco de dados faça um trabalho extra para cumprir os princípios DRY (como usar funções escalares ou exibições que chamam exibições ou consultas que retornam muitas colunas ou usar um cursor para adicionar 1000000 registros para usar um processo existente) é frequentemente contra-indicado. Não pense que, apenas porque algo é bom no mundo orientado a objetos, é apropriado no design do banco de dados. Seu voto negativo foi inapropriado. O uso do ID é um antipadrão conhecido do SQL.
HLGEM 20/10
31

Esta discussão está encerrada, mas eu gostaria de acrescentar que a IMO não usar Idé uma prática ruim. A Idcoluna é especial; é a chave primária. Qualquer tabela pode ter qualquer número de chaves estrangeiras, mas pode ter apenas uma chave primária. Em um banco de dados em que todas as chaves primárias são chamadas Id, assim que você olha para a tabela, sabe exatamente qual coluna é a chave primária.

Acredite, há meses que passo o dia inteiro todos os dias trabalhando em muitos bancos de dados grandes (Salesforce), e a melhor coisa que posso dizer sobre os esquemas é que todas as tabelas têm uma chave primária chamada Id. Posso garantir que absolutamente nunca me confundo sobre associar uma chave primária a uma chave estrangeira porque o PK é chamado Id. Outra coisa que as pessoas não mencionaram é que as tabelas podem ter nomes tolos e longos Table_ThatDoesGood_stuff__c; esse nome já é ruim o suficiente porque o arquiteto teve uma ressaca na manhã em que pensou nessa tabela, mas agora você está me dizendo que é uma prática ruim não chamar a chave primária Table_ThatDoesGood_stuff__cId (lembrando que os nomes das colunas SQL geralmente não diferenciam maiúsculas de minúsculas).

Para ser sincero, os problemas com a maioria das pessoas que ensinam programação de computadores são que eles não escrevem uma linha de código de produção há anos, se é que alguma vez, e não têm idéia do que realmente faz um engenheiro de software em funcionamento. Espere até começar a trabalhar e decida o que você acha que é uma boa ideia ou não.

user23157
fonte
2
Esse é o caso apenas se nenhuma das chaves primárias for uma chave composta, o que é, infelizmente, com muita freqüência. Deve-se realmente usar apenas chaves substitutas em circunstâncias particulares.
precisa
6
Usando o Id dessa maneira, você acaba com uma situação em que, sem pensar, os desenvolvedores adicionam o ID da chave primária a todas as tabelas que eles fazem. Um dos fundamentos dos bancos de dados relacionais é o uso de chaves primárias completas e agregadas e o uso de id não ajuda.
Pieter B
Essa resposta parece que você está dizendo "Prefiro ID" com argumentos opinativos. Seu argumento é que você pode ver instantaneamente qual chave é a chave principal localizando a chamada Id. Bem, é exatamente o mesmo com tableId . Posso garantir que nunca confundo qual chave é a chave primária também. Eu apenas procuro aquele que tem o nome da tabela antes do id. Não apenas isso, mas com que tipo de tabelas pagãs você trabalha onde a primeira coluna não é a chave primária? Eu sinto que todos os seus argumentos nesta resposta são puramente preferenciais e semelhantes a "tableId parece errado para mim".
dallin
@allin todas as respostas são opinativas, caso contrário alguém ligaria para o padrão oficial, e não há uma!
James
@ James Eu sinto que o objetivo dos sites StackExchange é reduzir as respostas opinativas. É por isso que as perguntas são encerradas por serem muito opinativas. Concedido, acho que é por isso que essa pergunta foi encerrada - porque gera respostas opinativas, mas acho que essa resposta específica foi excessivamente opinativa sem nenhum fato ou argumento de suporte real baseado em fatos. A resposta inteira pode ser resumida dizendo: "Em na minha opinião, você deve usar o Id, só porque é disso que eu gosto ". Essa não é uma resposta valiosa.
dallin 5/06
24

Não considero uma prática ruim. A consistência é rei, como sempre.

Eu acho que é tudo sobre contexto. Por si só, no contexto da tabela, "id" significa exatamente o que você espera, um rótulo para ajudar a identificá-lo exclusivamente contra outros que, de outra forma, poderiam ser (ou parecer) idênticos.

No contexto de junções, é sua responsabilidade construí-las de maneira a torná-las legíveis para você e sua equipe. Assim como é possível dificultar as coisas com fraseado ou nomeação, é igualmente possível construir uma consulta significativa com o uso eficaz de aliases e até comentários.

Da mesma forma que uma classe Java chamada 'Foo' não tem suas propriedades prefixadas por 'Foo', não se sinta obrigado a prefixar seus IDs de tabela com nomes de tabela. Geralmente, é claro no contexto qual é o ID a que se refere.

lotes fora do tempo
fonte
5
As tabelas de banco de dados relacional não são classes .
Adam Robinson
11
No entanto, são estruturas de dados e são análogas às classes PODO. Os mesmos problemas de nomenclatura se aplicam.
ocodo 18/10/11
4
@ Slomojo: Não, eles não são análogos a objetos simples. O design orientado a objetos e o design do banco de dados não são os mesmos e nem estão relacionados. Embora eles possam, em alguns casos, produzir um design semelhante (ou mesmo o mesmo), isso não indica que eles estão relacionados. Por exemplo, os relacionamentos m: m são triviais nas classes, mas são impossíveis de existir entre duas tabelas sem uma terceira tabela de associação.
Adam Robinson
11
Como isso se relaciona com uma estratégia de nomeação, eu não sei. Minha analogia é (claramente?) Apenas com escopo nessa extensão.
ocodo 18/10/11
2
Me desculpe, meu significado implícito não era muito claro, eu deveria ter dito " nesse sentido, eles são análogos às classes". De qualquer forma, não acho que ser excessivamente pedante sobre isso seja particularmente construtivo. Em termos de nomeação, tabelas e classes compartilham uma quantidade significativa de semelhanças. As melhores práticas desenvolvidas em um beco sem saída são um jogo justo para revisão ou, pelo menos, estão abertas à discussão. Há muitas perguntas e respostas nesta ilustração que ilustram isso de maneira eficaz. Não tenho mais nada a acrescentar.
ocodo 18/10/11
24

De data.stackexchange.com

Id nas postagens

BOOM, pergunta respondida.
Agora, diga ao seu professor que SO pratica um design ruim do banco de dados.

Cyril Gandon
fonte
8
Meu palpite nas FKs, com base nos nomes: PostTypeId -> PostTypes.Id; AcceptedAnswerId -> Answers.Id; OwnerUserId -> Users.Id. Por que uma prática tão fácil deve ser considerada "ruim"?
Sjoerd
3
Como isso prova exatamente as melhores práticas?
GBA
5
Se algo é usado na pilha ou não, isso não prova se é uma boa ou má prática.
Pieter B
2
O que isso prova é que essa prática de forma alguma proíbe a escalabilidade e utilidade de um aplicativo.
cifra
11
Na verdade, a prática não é perfeita. Eu usaria esta nomeação: PostType -> PostType.Id; AcceptedAnswer -> Answer.Id; Proprietário -> User.Id
alpav
17

Isso torna difícil (e confuso) realizar uma junção natural na mesa, portanto, sim, é ruim, se não muito ruim.

A junção natural é um artefato antigo do SQL Lore (ou seja, álgebra relacional) que você pode ter visto um destes: ⋈ talvez em um livro de banco de dados. O que eu quero dizer é que o Natrual Join não é uma nova idéia SQL distorcida, mesmo que pareça levar uma eternidade para os DBMS implementá-la; portanto, não é uma idéia distorcida para você implementá-la, pode até ser irracional você ignorar sua existência hoje em dia.

Bem, se você nomear o ID de toda a chave primária, perderá a facilidade e a simplicidade da junção natural. select * from dudes natural join carsprecisará ser escrito select * from dudes inner join cars where cars.dudeid = dudes.idou select * from dudes inner join cars where dudes.carid = cars.id. Se você é capaz de fazer uma junção natural, ignora o que realmente é a relação, o que, acredito, é bastante impressionante.

Peter Turner
fonte
A menos que você esteja gravando um procedimento armazenado, quando é a última vez que, como desenvolvedor de aplicativos, você realmente escreveu um seletor SQL totalmente formatado? Todos os idiomas modernos incluem algum tipo de recurso ORM que gerencia esse relacionamento para você. O nome da coluna é muito mais importante do que ser capaz de escrever SQL manual limpo.
Bill Leeper
4
@ Bill eu faço o tempo todo, muitas e muitas vezes por dia, depende mais da sua base de código do que da linguagem que você está desenvolvendo. E, para o diagnóstico, se você deseja fazer algumas boas e profundas relações, pode unir essas junções naturais e evitar completamente procurar IDs de campo. E, como São Jerônimo disse: "Ignorância de SQL é ignorância de bancos de dados".
Peter Turner
Além do fato de que as junções naturais não são universalmente suportadas, na IMO, as junções naturais são mais difíceis de ler. Existem duas colunas no relacionamento ou apenas uma? Muito melhor ser explícito e evitar junções naturais.
Thomas
11
@ Thomas, eu não colocaria junções naturais no código também, mas para o diagnóstico, eu as achei bastante úteis quando o banco de dados é modelado para que elas realmente funcionem.
Peter Turner
16

Há uma situação em que colar "ID" em todas as tabelas não é a melhor idéia: a USINGpalavra - chave, se for suportada. Nós o usamos frequentemente no MySQL.

Por exemplo, se você tiver fooTableuma coluna fooTableIde barTableuma 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 salva a 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)
Izkata
fonte
Esta é a resposta que mais se destaca para mim. A USINGpalavra-chave é suportada pelo banco de dados postgres / mysql / sqlite, significa menos digitação que algumas das outras respostas listam como razão para o uso ide, finalmente, na minha opinião subjetiva, é mais legível.
Michael Barton
11

Por que não perguntar ao seu professor?

Pense nisso: quando todas as colunas PK de suas tabelas são nomeadas ID, o uso delas como chaves estrangeiras é um pesadelo.

Os nomes das colunas precisam ser semanticamente significativos. IDé genérico.

user7519
fonte
8
muito genérico para quê? o id de uma mesa?
jim
3
@ Jim de qual tabela? idsozinho não significa nada, especialmente no contexto de uma chave estrangeira para outra tabela. Isso não tem nada a ver com, classese tudo a ver com um bom design básico básico de banco de dados relacional.
10
Para ser um pouco tatuado, a mesa a que pertence. table.idé uma maneira perfeitamente aceitável de se referir a um idcampo. Prefixar o nome do campo com o nome da tabela é redundante.
ocodo 18/10/11
2
@Slomoj não é mais digitar do que incluir o nome na coluna e mais explícito ao aliasar os nomes das tabelas para abreviações de uma ou duas letras nas junções de monstros.
6
De que pesadelo você está se referindo? Suponha que você tenha uma estrutura de auto-referência de funcionários com uma coluna representando seu gerente. Como você chama a chave estrangeira? Você não pode chamá-lo de EmployeeId, pois presumivelmente é o seu PK. O nome do FK não precisa corresponder ao PK. Deve ser nomeado pelo que representa para a entidade em que está contido.
Thomas
7

O ID está incorreto pelos seguintes motivos:

Se você faz muitas consultas de relatórios, sempre precisa usar o alias das colunas para ver as duas. Portanto, torna-se uma perda de tempo quando você pode nomear o nome corretamente para começar. Essas consultas complexas são difíceis o suficiente (escrevo consultas que podem ter centenas de linhas) sem o ônus adicional de fazer um trabalho desnecessário.

Está sujeito a causar erros de código. Se você usar um banco de dados que permita o uso da junção natural (não que eu ache que você deva usá-lo, mas quando houver recursos disponíveis, alguém os usará), você se juntará à coisa errada se conseguir um desenvolvedor que a use.

Se você estiver copiando associações para criar uma consulta complexa, é fácil esquecer de alterar o alias para o desejado e obter uma associação incorreta. Se cada ID for nomeado após a tabela em que está, geralmente você receberá um erro de sintaxe. Também é mais fácil identificar se a junção em uma consulta complexa está incorreta se o nome do pPK e o nome do FK corresponderem.

HLGEM
fonte
+1: essas são razões convincentes na minha opinião, enquanto as outras respostas opostas IDnão me convencem.
Phoog
Re: "Se você estiver copiando junções para criar uma consulta complexa" - seu problema é copiar e colar. Pare de copiar e colar e você verá como é conveniente nomear car.id. Para ingressar no FK, use car.mfg = mfg.id, car.color = color.id, car.model = model.id - muito simples e corresponde ao que você escreveria no LINQ.
alpav
Tente escrever algo com 30 junções e você verá por que é um antipadrão.
HLGEM
O alias é a primeira e principal razão - é uma dor de cabeça ao fazer grandes relatórios complexos. Associações naturais são apenas um bônus. É incrível como outras respostas simplesmente ignoram esses pontos. Acho que adicionar alguns exemplos tornaria o ponto mais claro e aumentaria essa resposta para onde deveria estar.
Lulu
5

Existem algumas respostas que se aproximam do que eu consideraria o motivo mais importante para não usar "id" como o nome da coluna da chave primária em uma tabela: a saber, consistência e ambiguidade reduzida.

No entanto, para mim, o principal benefício é alcançado pelo programador de manutenção, em particular aquele que não estava envolvido no desenvolvimento original. Se você usou o nome "PersonID" para o ID na tabela Person e o usou consistentemente como uma chave estrangeira, é trivial escrever uma consulta no esquema para descobrir quais tabelas têm PersonID sem precisar inferir que "PersonID" é o nome usado quando é uma chave estrangeira. Lembre-se, certo ou errado, os relacionamentos de chave estrangeira nem sempre são impostos em todos os projetos.

Há um caso de borda em que uma tabela pode precisar ter duas chaves estrangeiras na mesma tabela, mas, nesses casos, eu colocaria o nome da chave original como o nome do sufixo da coluna, para que uma correspondência curinga,% PersonID, pudesse encontrar facilmente essas instâncias também.

Sim, muito disso poderia ser conseguido com o padrão de ter "id" e saber usá-lo sempre como "tableNameID", mas isso exige que você saiba que a prática está em vigor e que depende dos desenvolvedores originais seguirem com menos prática padrão intuitiva.

Embora algumas pessoas tenham apontado que são necessárias algumas teclas extras para escrever os nomes mais longos das colunas, eu diria que escrever o código é apenas uma pequena fração da vida ativa do programa. Se salvar o pressionamento de teclas do desenvolvedor era o objetivo, os comentários nunca deveriam ser escritos.

Como alguém que passou muitos anos mantendo grandes projetos com centenas de tabelas, eu preferiria fortemente nomes consistentes para uma chave entre tabelas.

Malaquias
fonte
Suponha que uma Companiestabela tenha 2 chaves estrangeiras em uma Personstabela. Um representa o presidente da empresa; o outro representa o tesoureiro da empresa. Você realmente chamaria as colunas PersonID1e PersonID2? Seria muito mais descritivo chamá-los PresidentIDe TreasurerID. Acho que é muito mais fácil de ler inner join Person AS Presidents ON Company.PresidentID = Presidents.IDdo queinner join Person AS Person1 ON Company.PersonID1 = Person1.PersonID
phoog
11
Não. No seu exemplo, eu provavelmente teria uma tabela CompanyOfficerou CompanyPersonque permita um relacionamento muitos para muitos entre Companye Personcom informações adicionais sobre a natureza do relacionamento. Se fosse para implementá-lo na Companytabela, usaria os nomes das colunas PresidentPersonIDe TreasurerPersonIDpreservaria a parte * PersonID do nome ao adicionar o descritor adicional. inner join Person as Presidents on Company.PresidentPersonID = Presidents.PersonID
Malaga,
5

A prática de usar o ID como campo de chave primária leva à prática em que o ID é adicionado a todas as tabelas. Muitas tabelas já possuem informações exclusivas que identificam exclusivamente um registro. Use ISTO como chave primária e não um campo de ID que você adiciona a cada tabela. Essa é uma das bases dos bancos de dados relacionais.

E é por isso que usar o id é uma prática ruim: o id geralmente não é uma informação apenas um aumento automático.

considere as seguintes tabelas:

PK id | Countryid   | Countryname
    1 |         840 | United States
    2 |         528 | the Netherlands

O que há de errado com esta tabela é que ela permite que o usuário adicione outra linha: Estados Unidos, com o código do país 840. Isso acabou com a integridade relacional. É claro que você pode impor exclusividade em colunas individuais ou simplesmente usar uma chave primária que já esteja disponível:

PK Countryid   | Countryname
           840 | United States
           528 | the Netherlands

Dessa forma, você usa as informações que já possui como chave primária, que está no centro do design de banco de dados relacional.

Pieter B
fonte
11
Você entenderá por que as pessoas adicionam uma coluna de chave genérica a todas as tabelas quando você precisa migrar bancos de dados entre sistemas diferentes ou teve o prazer de mesclar bancos de dados.
cifra
11
Ocasionalmente, mas na minha experiência, é bastante incomum ter uma chave imutável única e agradável. Mas mesmo no seu exemplo, você tem um número exclusivo sem sentido para identificar países, apenas um que é alocado pela ISO e não pelo seu banco de dados.
#
E agora, quando o nome do país mudar, você precisará atualizá-lo em todo o banco de dados para corrigir. Se você tivesse simplesmente usado uma chave substituta (como ... "id"), a atualização seria trivial. As chaves naturais são ótimas - quando são completamente imutáveis ​​e nunca mudam. Na verdade, existem muito poucos casos em que isso é verdade.
Gerrat 6/0318
@Gerrat: Se o nome de um país mudar, o código numérico ISO 3166-1 permanece o mesmo, apenas os códigos ISO 3166-1 alfa-2 e alfa-3 mudam. Isso aconteceu com a Birmânia / Mianmar, por exemplo. Da mesma forma, se um país altera seu território, mas mantém seu nome, o código numérico ISO 3166-1 é alterado, mas os códigos ISO 3166-1 alfa-2 e alfa-3 permanecem. Isso aconteceu quando o Sudão do Sul se separou do Sudão e a Eritreia se separou da Etiópia. Quando a Alemanha Oriental e Ocidental se reuniram, eles mantiveram os códigos alfa-2 e alfa-3 da Alemanha Ocidental, mas obtiveram um novo código numérico. Quando os países se dissolvem ou se transformam completamente (pense…
Jörg W Mittag
… Resultado das guerras dos Balcãs nos anos 90), eles obtêm novos códigos numéricos e alfa-2 e alfa-3.
Jörg W Mittag
4

Eu sempre uso 'id' como o nome da coluna principal para todas as tabelas, simplesmente porque é a convenção das estruturas que eu uso (Ruby on Rails, CakePHP), para que eu não precise substituí-lo o tempo todo.

Isso não vai superar as razões acadêmicas para mim.

Sfynx
fonte
2

Não acho que seja uma prática ruim se usada corretamente. É comum ter um campo de ID de incremento automático chamado "ID" que você nunca precisa tocar e usar um identificador mais amigável para o aplicativo. Pode ser um pouco complicado escrever código, from tableA a inner join tableB b on a.id = b.a_idmas esse código pode ser escondido.

Como preferência pessoal, costumo prefixar o ID com o nome da entidade, mas não vejo um problema real ao usar apenas Idse ele for tratado inteiramente pelo banco de dados.

Wayne M
fonte
Você nunca juntaria duas tabelas pela chave primária de cada uma, especialmente um ID de incremento automático. O exemplo acima seria da tabela A uma tabela de junção internaB b em a.id = b.table_a_id.
Bill Leeper
Sim, foi isso que eu quis dizer. Quase na hora do almoço e preciso de energia.
Wayne Molina
2

O ID é bastante comum, e acho que isso não confundiria ninguém. Você sempre vai querer conhecer a mesa. Colocar nomes de campos no código de produção sem incluir uma tabela / alias é uma prática ruim. Se você está preocupado demais em poder digitar rapidamente consultas ad hoc, está por sua conta.

Espero que ninguém desenvolva um banco de dados sql em que ID seja uma palavra reservada.

CREATE TABLE CAR (ID);

Cuida do nome do campo, da chave primária e dos incrementos automáticos em 1 começando com 1, tudo em um pequeno e agradável pacote de 2 caracteres. Ah, e eu chamaria isso de CARS, mas se vamos economizar com o pressionamento de teclas e quem realmente acha que uma mesa chamada CAR terá apenas um?

JeffO
fonte
11
isso mostra por que o conhecimento da teoria relacional formal é importante, o nome da tabela representa o que é uma única linha . A tabela Carrepresenta um Tableonde cada Rowum representa um único Car. A chamada Carsmuda a semântica e mostra uma completa falta de entendimento dos princípios básicos da teoria relacional formal. O Rails é um excelente exemplo de alguém que sabia o suficiente para ser perigoso .
2

Essa pergunta foi repetida várias vezes, mas pensei em acrescentar minha opinião.

  1. Uso id para significar que esse é o identificador de cada tabela; portanto, quando ingresso em uma tabela e preciso da chave primária, ingresso automaticamente na chave primária.

  2. O campo id é um incremento automático, sem sinal (o que significa que nunca preciso definir seu valor e não pode ser negativo)

  3. Para chaves estrangeiras, eu uso tablenameid (novamente uma questão de estilo), mas a chave primária na qual ingresso é o campo id da tabela, portanto, a consistência significa que sempre posso verificar consultas facilmente

  4. id é curto e doce também

  5. Convenção adicional - use letras minúsculas para todos os nomes de tabelas e colunas, para que nenhum problema seja encontrado devido a maiúsculas e minúsculas

Stephen Senkomago Musoke
fonte
1

Outra coisa a considerar é que, se o nome da chave primária for diferente do nome da chave estrangeira, não será possível usar certas ferramentas de terceiros.

Por exemplo, você não conseguiria carregar seu esquema em uma ferramenta como o Visio e produzir ERDs precisos.

Martijn Pieters
fonte
Isso seria culpa da ferramenta de terceiros. As convenções de nomenclatura de colunas não substituem as chaves estrangeiras reais, que a ferramenta deve examinar.
Gerrat 11/06
1

Acho que as pessoas aqui cobrem praticamente todos os aspectos, mas quero acrescentar que "id" não é e não deve ser lido como "identificador", é mais um "índice" e certamente não indica nem descreve a identidade da linha. (Talvez eu tenha usado palavras erradas aqui, corrija-me se o fizesse)

É mais ou menos como as pessoas leem os dados da tabela e como escrevem seu código. Pessoalmente, e provavelmente essa é a maneira mais popular que vejo com mais frequência é que os codificadores escrevem a referência completa como table.id, mesmo que não precisem fazer união ou união. Por exemplo:

SELECT cars.color, cars.model FROM cars WHERE cars.id = <some_var>

Dessa forma, você pode traduzi-lo para o inglês como "Dê-me a cor e o modelo do carro que está numerado como". e não como "Dê-me a cor e o modelo do carro identificado como número". O ID não representa o carro de forma alguma, é apenas o índice do carro, um número de série, se você desejar. Assim como quando você deseja pegar o terceiro elemento de uma matriz.

Então, para resumir o que eu queria adicionar, é apenas uma questão de preferência e a maneira descrita de ler SQL é a mais popular.

No entanto, existem alguns casos em que isso não é usado, como (um exemplo muito mais raro) quando o ID é uma string que está realmente descrevendo. Por exemplo id = "RedFordMustang1970"ou algo semelhante. Eu realmente espero poder explicar isso pelo menos para ter uma idéia.

Sergey Telshevsky
fonte