Convenções e práticas recomendadas para nomeação de nomes de colunas

19

Gostaria de receber uma opinião de especialistas sobre as melhores práticas quando se trata de nomeação de colunas .

O pano de fundo é que, de acordo com a Wikipedia , a seguinte sintaxe,

SELECT ... FROM Employees JOIN Timesheets USING (EmployeeID);

é mais eficiente que

SELECT ... FROM Employees JOIN Timesheets ON (Employees.EmployeeID = Timesheets.EmployeeID);

No entanto, a JOIN ... USINGsintaxe funciona apenas de todas as colunas da chave primária com nomes exclusivos globalmente . Assim, eu me pergunto se isso é considerado a coisa certa a ser feita.

Pessoalmente, eu sempre costumava criar tabelas com coluna PK ide coluna de chave estrangeira othertable_id. Mas dessa forma não é possível usar USINGou NATURAL JOIN.

Quaisquer links para estilos de design ou guias de práticas recomendadas para design de tabelas também serão apreciados!

database-design join naming-convention

— Kerrek SB
fonte

3

A Wikipedia está errada. A primeira versão não é mais eficiente que a segunda. Sob o capô o banco de dados irá criar absolut consultas idênticas

— a_horse_with_no_name

13

Isso já foi solicitado anteriormente no SO.

Onde você tiver nomes comuns e muito ambíguos, prefixe o nome da tabela. Ou seja, qualquer coisa que você precise alias em quase todas as consultas.

Então, para uma tabela de funcionários, eu teria

EmployeeID
EmployeeName
Comment
Salary
StartDate
EndDate
InsertedDateTime
...

E a Wikipedia realmente diz:

A construção USING é mais do que mero açúcar sintático, no entanto, uma vez que o conjunto de resultados difere do conjunto de resultados da versão com o predicado explícito. Especificamente, todas as colunas mencionadas na lista USING aparecerão apenas uma vez, com um nome não qualificado, em vez de uma vez para cada tabela na associação.

Essa é uma coluna a menos. Você nunca usaria de SELECT *qualquer maneira, então o ponto é discutível ...

— gbn
fonte

Eu não tinha pensado em procurar algo tão bobo. Você tem links para perguntas particularmente boas sobre o SO? De qualquer forma, obrigado, vou manter o nome de "ID único" daqui em diante!

— Kerrek SBJ

@Kerrk SB: na verdade, eu não tenho. I tendem a ignorá-los, porque cada um é respondida ou fechada rapidamente :-) Desculpe

— GBN

Eu gostaria de ver essas perguntas semelhantes no SO, se alguém puder desenterrar um link. Eu vim aqui porque não consegui encontrar uma pergunta lá e tinha certeza de que já havia sido feita. Eu imediatamente encontrei essa pergunta.

— 21130 Nicholas Shanks

Foi em programadores.SE. Uma boa luta de

— coelhos

6

O livro a seguir fala sobre o uso do ID como antipadrão do SQL e concordo com o autor. http://www.amazon.com/SQL-Antipatterns-Programming-Pragmatic-Programmers/dp/1934356557/ref=sr_1_1?s=books&ie=UTF8&qid=1330025134&sr=1-1

Esse é um problema específico quando você está gerando relatórios complexos e precisa de mais de um ID, pois precisa usar o alias. O uso do ID do nome da tabela também facilita a identificação do FK correto para ingressar (pois eles têm o mesmo nome) e torna menos provável a ocorrência de erros ao ingressar na coisa errada.

Dito isso, muitos bancos de dados não suportam a sintaxe USING, o que torna o problema que você trouxe à tona não um problema para esses bancos de dados.Nem muitos bancos de dados suportam o uso de uma junção natural que eu não recomendaria o uso de qualquer forma, pois eles podem mudar. se as estruturas da tabela mudarem. Então, suponha que você adicione um campo chamado data modificada às duas tabelas, não desejaria ingressar nisso, mas a associação natural o faria.

— HLGEM
fonte

4

É melhor fornecer explicitamente o nome da tabela e o nome da coluna como Employees.EmployeeID com expressões em que existe uma associação

— Eralper
fonte