Por atributos especificar chave primária / estrangeira em nomes de coluna

Question

Um par de perguntas recentes discutir estratégias para colunas de nomeação, e eu estava um pouco surpreso ao descobrir o conceito de incorporar a noção de chaves estrangeiras e primárias em nomes de coluna. Isso é

select t1.col_a, t1.col_b, t2.col_z
from t1 inner join t2 on t1.id_foo_pk = t2.id_foo_fk

Eu tenho que confessar que eu nunca trabalhou em qualquer sistema de banco de dados que usa esse tipo de esquema, e eu estou querendo saber quais são os benefícios. A forma como eu vejo, uma vez que você aprendeu as principais tabelas de N de um sistema, você vai escrever várias ordens de magnitude mais pedidos com essas tabelas.

Para se tornar produtivo em desenvolvimento, você vai precisar aprender quais tabelas são as tabelas importantes, e que são afluentes simples. Você vai querer cometer um bom número de nomes de coluna para a memória. E uma das tarefas básicas é juntar duas mesas juntos. Para reduzir o esforço de aprendizagem, a melhor coisa a fazer é garantir que o nome da coluna é o mesmo em ambas as tabelas:

select t1.col_a, t1.col_b, t2.col_z
from t1 inner join t2 on t1.id_foo = t2.id_foo

Eu postular que, como um desenvolvedor, você não precisa de ser lembrado que muito sobre quais colunas são chaves primárias, que são estranhos e que não são nada. É fácil o suficiente para olhar para o esquema, se você está curioso. Ao olhar para um aleatória

tx inner join ty on tx.id_bar = ty.id_bar

... é tudo o que importante saber qual é a chave estrangeira? As chaves estrangeiras são importantes apenas para o motor de banco de dados próprio, para permitir que ele para garantir a integridade referencial e fazer a coisa certa durante atualizações e exclusões.

O problema está sendo resolvido aqui? (Eu sei que isto é um convite para discutir, e não hesite em fazê-lo. Mas, ao mesmo tempo, eu am em busca de uma resposta, em que eu possa ser realmente faltando alguma coisa).

Answer 1

Eu concordo com você que a coluna de chave estrangeira em uma tabela filho deve ter o mesmo nome que a coluna de chave primária na tabela pai. Note-se que esta sintaxe licenças como o seguinte:

SELECT * FROM foo JOIN bar USING (foo_id);

A palavra-chave usando assume que uma coluna existe com o mesmo nome em ambas as tabelas, e que você quer uma junção de igualdade. É bom ter esta disponível como uma abreviação para o mais detalhado:

SELECT * FROM foo JOIN bar ON (foo.foo_id = bar.foo_id);

Note, no entanto, há casos em que você não pode nomear a chave estrangeira a mesma que a chave primária faz referência. Por exemplo, em uma tabela que tem uma auto-referência:

CREATE TABLE Employees (
  emp_id INT PRIMARY KEY,
  manager_id INT REFERENCES Employees(emp_id)
);

Também uma tabela pode ter várias chaves estrangeiras para mesma tabela pai. É útil usar o nome da coluna para descrever a natureza do relacionamento:

CREATE TABLE Bugs (
  ...
  reported_by INT REFERENCES Accounts(account_id),
  assigned_to INT REFERENCES Accounts(account_id),
  ...
);

Eu não gosto de incluir o nome da tabela no nome da coluna. Eu também evitam o "id" obrigatória como o nome da coluna de chave primária em cada tabela.

Answer 2

Eu concordo com você. Colocar esta informação nos cheira nome da coluna da porcaria idiotice Hungarian Notation dos primeiros dias do Windows.

Answer 3

Eu tenho defendido a maioria das idéias aqui proposta ao longo dos anos 20-ish Eu estive em desenvolvimento com bancos de dados SQL, tenho vergonha de dizer. A maioria deles entregues poucos ou nenhum dos benefícios esperados e foram em retrospectiva, uma dor no pescoço.

Qualquer tempo que passei mais do que algumas horas com um esquema que eu muito rapidamente se familiarizar com os quadros mais importantes e suas colunas. Uma vez chegou a alguns meses, eu praticamente tem a coisa toda na minha cabeça.

Quem é toda essa explicação para? Alguém que gasta apenas alguns minutos com o projeto não vai estar fazendo algo sério de qualquer maneira. Alguém que planeja trabalhar com ele por um longo tempo vai aprender se você nomeou suas colunas em sânscrito.

Ignorando as chaves primárias compostas, eu não vejo por que algo tão simples como "id" não será suficiente para uma chave primária, e "_id" para chaves estrangeiras.

Assim, uma típica condição de junção torna-se customer.id = order.customer_id.

Quando mais de uma associação entre duas tabelas existe, eu estaria inclinado a usar a associação, em vez do nome da tabela, então talvez "parent_id" e "child_id" em vez de "parent_person_id" etc

Answer 4

Eu só uso o tablename com um sufixo Id para a chave primária, por exemplo, Cliente, e estrangeiros chaves referenciando que a partir de outras tabelas também seria chamado CustomerId. Ao fazer referência na aplicação torna-se óbvio a partir da tabela as propriedades do objecto, por exemplo Customer.TelephoneNumber, Customer.CustomerId, etc.

Answer 5

Eu usei "fk_" na extremidade dianteira de quaisquer chaves estrangeiras para uma mesa principalmente porque ele me ajudou a mantê-lo em linha reta ao desenvolver o DB para um projeto na minha loja. Não tendo feito qualquer trabalho DB no passado, isso me ajudou. Em retrospectiva, talvez eu não precisava fazer isso, mas foi três personagens tacked para alguns nomes de colunas para que eu não se preocupe.

Sendo um recém-chegado ao escrever aplicativos de banco de dados, eu pode ter feito algumas decisões que fariam um tremor desenvolvedor DB temperado, mas eu não tenho certeza que a coisa chave estrangeira é realmente esse negócio um grande. Mais uma vez, eu acho que é uma diferença de ponto de vista sobre esta questão e eu certamente vou levar o que você escreveu e cogitate sobre ele.

Tenha um bom dia!

Answer 6

Eu concordo com você - eu ter uma abordagem diferente que eu já vi recomendado em muitos ambientes corporativos:

colunas nome no formato TableNameFieldName , então se eu tinha uma tabela de clientes e UserName foi um dos meus campos, o campo seria chamado CustomerUserName. Isso significa que se eu tivesse outra tabela chamada fatura, eo nome de usuário do cliente era uma chave estrangeira, eu chamaria isso de InvoiceCustomerUserName, e quando eu referenciados, eu chamaria isso de Invoice.CustomerUserName, o que imediatamente me diz qual a tabela que está.

Além disso, esta nomeação ajuda você a manter o controle das tabelas suas colunas são provenientes de quando você está joiining.

Eu só uso FK_ e PK_ nos nomes reais das chaves estrangeiras e primárias nos DBMS.