Vendo isso da perspectiva de um dicionário de dados formal, eu nomearia o elemento de dados invoice_ID
. Geralmente, um nome de elemento de dados será único no dicionário de dados e, idealmente, terá o mesmo nome em todo o período, embora às vezes termos de qualificação adicionais possam ser necessários com base no contexto, por exemplo, o elemento de dados nomeado employee_ID
pode ser usado duas vezes no organograma e, portanto, qualificado como supervisor_employee_ID
e subordinate_employee_ID
respectivamente.
Obviamente, as convenções de nomenclatura são subjetivas e uma questão de estilo. Acho que as diretrizes ISO / IEC 11179 são um ponto de partida útil.
Para o SGBD, vejo as tabelas como coleções de entidades (exceto aquelas que contêm apenas uma linha, por exemplo, tabela cofig, tabela de constantes, etc.), por exemplo, a tabela onde my employee_ID
é a chave seria nomeada Personnel
. Então, de imediato, a TableNameID
convenção não funciona para mim.
Já vi o TableName.ID=PK TableNameID=FK
estilo usado em modelos de dados grandes e devo dizer que o acho um pouco confuso: prefiro muito mais que o nome de um identificador seja o mesmo, ou seja, não muda o nome com base na tabela em que aparece. Algo a ser observado é o estilo mencionado acima parece ser usado nas lojas que adicionam uma IDENTITY
coluna (auto-incremento) a todas as tabelas, enquanto evitam as chaves naturais e compostas nas chaves estrangeiras. Essas lojas tendem a não ter dicionários de dados formais nem construir a partir de modelos de dados. Novamente, esta é apenas uma questão de estilo e que eu pessoalmente não concordo. Então, no final das contas, não é para mim.
Dito isso, às vezes vejo um caso de descartar o qualificador do nome da coluna quando o nome da tabela fornece um contexto para fazer isso, por exemplo, o elemento nomeado employee_last_name
pode se tornar simplesmente last_name
na Personnel
tabela. O raciocínio aqui é que o domínio é 'sobrenomes de pessoas' e é mais provável que seja UNION
editado com last_name
colunas de outras tabelas em vez de ser usado como uma chave estrangeira em outra tabela, mas, novamente ... Posso apenas mudar de ideia, às vezes você nunca sabe. É isso: modelagem de dados é parte arte, parte ciência.