É pobre de codificação prática para ter uma tabela SQL que contém uma coluna com o mesmo nome?

Question

Exemplo:

CREATE TABLE ErrorNumber
(
     ErrorNumber int,
     ErrorText varchar(255),
)

Isso pode resultar em consultas que olhar como:

SELECT ErrorNumber FROM ErrorNumber WHERE ErrorNumber=10

Answer 1

Estou assumindo que ErrorNumber como uma coluna na tabela é uma chave primária? Neste caso, você poderia nomear o ErrorNumberID coluna da tabela.

Eu não sei sobre ele ser uma prática de codificação pobres, mas eu não posso imaginar que está fazendo nada para facilitar a leitura. O exemplo que você forneceu é grande em mostrar como confundir as consultas podem acabar sendo.

A outra coisa que eu não tenho certeza é se isso (os nomes das colunas sendo o mesmo que os nomes de tabela) causaria um erro? Tenho certeza de que varia de um fornecedor para outro.

Answer 2

CREATE TABLE Errors (
    Number int,
    Description varchar(255)
)

Eu sinto o acima é um esquema melhor nomear porque:

• O nome da tabela agora representa o que é.
• As colunas não precisa da palavra "Erro" neles por causa da mesa eles estão em.

Answer 3

Você poderia cumpri-padrão eo nome do seu ID de chaves primárias.

Answer 4

Eu não acho que é uma boa idéia ter uma coluna que compartilham o mesmo nome com a sua mesa. É confuso mesmo se ele funciona. Tente mudar o nome da tabela para erro ou a coluna para ERRORNUM ou mesmo apenas Num

Answer 5

Sim, é. A grande maioria das tabelas simples em modelos de dados simples deve ser plural substantivos. No seu exemplo, a tabela deve ser chamado "erros", com duas colunas, "id" e "descrição".

Answer 6

Eu concordo com DWC, e iria levá-la um passo adiante em nomear a mesa algo um pouco mais descritivo, como em que tipo de tabela de erros é. Se ele é usado para erros de loja que você vai usar em seu código é uma coisa, e se a sua mesa um que os erros de registros é outra. Não sei o que você está usando para isso, por isso é realmente até você para nomeá-lo algo que faz sentido para o contexto é usado para. não quando eu ver uma tabela chamada "Erros" Estou certo de que, se sua tabela de log um, ou uma tabela de pesquisa usado para encontrar códigos de erro. Se for o último do que talvez algo como ErrorCodes seria um bom nome.

CREATE TABLE ErrorCodes
(
Id int,
Number int,
Description varchar(255)
)

Answer 7

É pobre? Talvez um pouco, mas não é nada importante.

Answer 8

Eu concordo que é nada grave.

Temos skads de mesas em um aplicativo que tem somente e id e um campo "nome". Eles são usados ??para listas suspensas.

Então, eu configurá-los como este:

O nome da lista é: State

O nome da tabela é: State

O ID é: StateID

A coluna valor de estado real é: StateName

Ele funciona para nós.

No seu caso específico, eu faria como sugerido acima e apenas nomear o erro tabela.

Answer 9

Se qualquer fornecedor de banco de dados fica confuso com isso, usar outro fornecedor de banco de dados. Qualquer banco de dados deve analisar facilmente que, sem problema.

Eu concordo que provavelmente não é uma boa prática por razões de legibilidade.

Answer 10

É uma questão de forma. Pessoalmente, eu fazer a maioria dos nomes de tabela plural, então ele nunca iria acontecer. Neste caso particular, a minha mesa seria ErrorNumbers e o campo da tabela seria ErrorNumber (na verdade eu usaria ErrorNumberID)

Novamente, porém, cabe a você ou suas empresas padrões de codificação. Se é má forma, é uma violação extremamente menor. Se qualquer coisa, o seu ID em falta no nome da variável que é mais de uma violação.

Answer 11

Se uma tabela é esperado que compreendem mais de uma linha, em seguida, a minha preferência é usar um termo coletivo como um nome. Note que este não é o mesmo que tomando o singular e acrescentando um 's' g Eu prefiro 'Pessoal' e 'Folha' over 'Employees' e 'EmployeesSalaries' respectivamente. E um nome como 'Entitys' deve ser retirado e tiro:)

À luz disto, e considerando as colunas em seu projeto, gostaria de citar a mesa em 'erros' de interrogação. Agora, eu sei que muitos programadores preferem termos singulares para nomes de tabelas, mas isso é apenas um estilo diferente, em vez de 'prática de codificação pobres'.

Existem necessidades ocasionais para tabelas de uma carreira por exemplo uma tabela 'Constantes' contendo a aproximação compartilhada de pi para ser usado por aplicativos que usam os DBMS ... mas, em seguida, a mesa 'Constantes' eu tenho em mente tem várias colunas cada para uma constante diferente, por isso recebe um termo coletivo como um nome .

Talvez se seus aplicativos só usei uma constante, então talvez você pode acabar com uma tabela chamada 'Pi'? Bem, outra opção de estilo que eu fiz é usar UpperCamelCase para nomes de tabelas e lower_case_separated_by_underscores para nomes de coluna. Portanto, eu ainda ser capaz de distinguir (quase) a tabela da coluna ou seja

SELECT pi FROM Pi;

[E um analisador de código como o que aqui no SO torna o trabalho mais fácil também!]

Na verdade, eu tendem a usar nomes de correlação de mesa quase exclusivamente então eu seria mais provável para escrever:

SELECT P1.pi 
  FROM Pi AS P1;

Considere também que alguns termos coletivos estão escritas as mesmas que o termo singular por exemplo 'espécies', 'veado', 'ovelhas', 'peixes' e provavelmente muitos outros não pertencentes ao reino animal, mas estou tendo um bloqueio mental agora:)

Assim, enquanto eu posso prever uma tabela SQL que contém uma coluna com o mesmo nome, mesmo com os meus dados preferido convenção elemento nomeação, seria uma ocorrência rara.

Answer 12

+1 para nomes sucintos de DwC.

O problema com "um nome de coluna deve significar um domínio de valores" é que ele tem vista para contexto. Um nome de coluna existe única no contexto de uma mesa. Nunca é ambígua. Seu domínio é controlada independentemente de seu nome.

O exist pessoa que não pode distinguir entre Errors.Description e Parts.Description e Problems.Description, ou que iria assumir que todas as colunas nomeadas Description ou Name são retirados do mesmo poço santo?

Dito isto, eu não usar termos genéricos como Número ou ID para colunas de chave primária, por uma razão muito diferente: a coluna precisa de um novo nome, onde ele aparece como uma chave estrangeira.

números de erro Suponha que teve que ser gravado em, digamos, a tabela de Actions. Actions.Number não pode referir-se a um número de erro, por isso estamos obrigados a inventar algo como Actions.ErrorNumber. Se ele vai ser ErrorNumber em qualquer outro lugar, ele poderia muito bem ter o mesmo nome, onde ele serve como a chave!