Uma pergunta que me faço com bastante frequência é: Se minha tabela é nomeada articles, devo nomear minha coluna article_numberou simplesmente number?
Existe uma boa prática? Existe alguma diferença se você cria tabelas e colunas em um banco de dados, ou trabalha em uma camada abstrata como um ORM, onde a consulta talvez seja
a = Article.get(1);
my_num = a.number;
// or
my_num2 = a.article_number
Eu faria article_id. É tentador apenas torná-lo "id", mas quando ele começa a se tornar um FK em outras tabelas, é bom ter a coluna com o mesmo nome em ambos os lados.
SQL emprega um conceito conhecido como integridade de nome de domínio , o que significa que os nomes dos objetos têm um escopo dado pelo seu contêiner.
Os nomes das colunas devem ser exclusivos, mas apenas dentro do contexto da tabela que contém as colunas. Os nomes das tabelas devem ser exclusivos, mas apenas dentro do contexto do esquema que contém as tabelas, etc.
Ao consultar colunas, você precisa fazer referência ao esquema, tabela e coluna em que está interessado, a menos que um ou mais deles possam ser inferidos. Ao escrever uma consulta, você precisa fazer referência às tabelas em sua consulta diretamente pelo nome ou usando um alias, por exemplo, Customer.ID ou C.ID do Cliente C, etc., a menos que sua consulta seja tão simples que faça referência apenas a um tabela.
Houve um tempo em que havia um requisito técnico para exclusividade de todos os nomes de coluna, que se aplicava a bancos de dados ISAM antigos e a linguagens como COBOL nas décadas de 1960 e 1970. Isso foi arrastado sem uma boa razão para o dBase na década de 1980 e ficou como uma convenção nas eras do DBMS relacional e de objetos. Resista a essa convenção ultrapassada.
Quando a mudança de arquivos simples e bancos de dados de rede para bancos de dados relacionais aconteceu nas décadas de 1970 e 1980, a ideia de unir tabelas era nova. Assim, algumas pessoas escolheram a convenção de que um nome único poderia ser repetido se uma coluna fosse uma referência a outra (ou seja, chaves estrangeiras). Esse conceito é chamado de "junção natural" e muitas pessoas ainda defendem isso.
Eu não sou um fã de junções naturais porque exige que você, em última análise, jogue fora o conceito de integridade do nome de domínio e force a referência de coluna inteira no nome da coluna.
O problema com as junções naturais é que você precisa ser hipócrita ou tornar os nomes das colunas longos e ilegíveis. Deixe-me ilustrar: pode parecer uma boa ideia que a chave primária da tabela Customer seja CustomerID. Em seguida, na tabela de faturas, sua chave estrangeira para o cliente também é chamada de CustomerID. Esta seria uma junção natural e tudo soa bem até agora. Aqui está o problema. E se sua convenção for ter uma coluna em cada tabela chamada LastUpdatedDate? Então você pretende unir todas as tabelas a todas as outras tabelas por LastUpdatedDate? Claro que não. Este é o absurdo das junções naturais. Para evitar esse absurdo, você precisaria inserir o nome da tabela no nome da coluna como um prefixo. No entanto, se você tiver vários esquemas em seu banco de dados, não poderá parar por aí. Você também precisa adicionar o esquema ao nome da coluna,
Outro lugar onde as junções naturais são quebradas é quando você tem vários relacionamentos entre as mesmas duas tabelas. Você, se precisar de duas referências a Employee em sua tabela Invoice (Sold By e Approved By, por exemplo), não poderá chamá-las de EmployeeID.
Esta não é uma questão de "melhores práticas". As melhores práticas são métodos a serem usados que você sabe que trarão o melhor desempenho do sistema. Os nomes dos campos não afetam em nada o desempenho. Os nomes de campo são estritamente o que você mais se sente confortável, embora muitas empresas codifiquem esses padrões em um documento em algum lugar. (E a maioria das empresas faz um trabalho tão ruim que às vezes sinto vontade de chorar. Mas essa é uma resposta para uma pergunta completamente diferente.)
Suponho que por "minha coluna" você quer dizer a chave substituta. Minha preferência ao nomear um campo-chave substituto é simplesmente ID. Meu raciocínio é que o nome deve refletir o significado do campo e o significado de qualquer campo (como a definição de qualquer palavra) é determinado pelo contexto. Dentro de uma definição de tabela, o nome "ID" significa "este é o PK desta tabela".
Então, quando estou olhando para os nomes das colunas de uma tabela e vejo "ID", sei que é o campo-chave substituto dessa tabela. Pode haver muitas colunas denominadas This_ID ou That_ID ou Other_ID. Se uma delas pode ser a chave para esta tabela e as outras chaves estrangeiras para outras tabelas, existe agora um pouco de ambiguidade nos nomes. Quando a chave desta tabela é ID e todos os outros campos XXX_ID são chaves estrangeiras, há menos ambiguidade.
Sinto muito, mas a ideia de que você terá o mesmo nome em ambos os lados de uma definição de chave estrangeira é apenas um pensamento preguiçoso. Em primeiro lugar, você estará olhando para nomes de campo e não scripts de definição FK, então você não verá esses nomes emparelhados, de qualquer maneira. Em segundo lugar, os nomes não serão os mesmos de qualquer maneira. Se você tiver referências de chave estrangeira para, digamos, a tabela Employees, essas referências terão nomes como Mgr_ID, Lead_ID, ApprovedBy, CheckedInBy, CheckedOutBy, CreatedBy, UpdatedBy, etc. Muito poucas referências serão realmente nomeadas Employee_ID. Isso é verdade para a maioria das chaves estrangeiras.
Essa resposta, é claro, se aplica apenas a chaves substitutas. As chaves primárias que são uma das chaves naturais serão nomeadas de acordo com o significado do atributo. VIN para a mesa Carros, SSN para a mesa Clientes e assim por diante. Mesmo esses campos terão nomes diferentes em outras tabelas: Rental_ID, AccountOwner, etc.
Dê nomes aos campos que sejam significativos no contexto estabelecido pela própria tabela. Quando você observa a definição de uma chave substituta, ela não deve ter nenhum outro uso (definição) além de "chave primária desta tabela". Assim, para mim, o nome não deve ser outro senão o "ID" genérico.