Qual padrão devo seguir ao nomear tabelas e visualizações?

20

Qual padrão devo seguir ao nomear tabelas e visualizações? Por exemplo, é uma boa ideia colocar algo como tbl_ no início dos nomes das tabelas? Devo designar tabelas de código / pesquisa de alguma forma, como ct_, lut_ ou codes_? Existem outros prós e contras?

Estou usando o MS SQL Server e tenho muitos bancos de dados com muitas tabelas, então seria bom ter algo que possamos usar como padrão com algum suporte racional.

relational-theory naming-convention

— Beth Whitezel
fonte

29

OK, primeiro NUNCA coloque tbl na frente do nome de uma tabela. É uma mesa, nós já agora isso. Isso se chama Notação Húngara e as pessoas pararam de fazer isso há mais de 5 anos.

Basta chamar o objeto com base no que é. Se uma tabela possuir dados de funcionários, chame-a de "Funcionário". Se ele contém informações sobre computadores, chame-o de "Computador". Se ele mapeia computadores para funcionários, chame-o de "EmployeeComputer" ou "ComputerEmployee" (pessoalmente, eu gosto mais de "EmployeeComputer").

Não há nenhuma convenção de nomenclatura correta para usar (exceto para não usar a notação húngara). Desde que os nomes dos objetos façam sentido, é o que é importante.

— Mrdenny
fonte

11

Além disso, por favor, não coloque os nomes das tabelas como substantivos plurais, como já vi exemplos de Funcionários, Cumputadores. Todos sabemos que as tabelas devem ter muitas linhas, não uma ..

— Marian

11

Por que você criaria visualizações de uma tabela? Tudo que uma visualização é, é uma instrução de seleção armazenada. Os dados não são materializados atrás de uma exibição, a menos que você esteja usando uma exibição indexada. Eu praticamente nunca uso vistas, nunca usei. Certamente não há nenhum benefício em desempenho para isso.

— mrdenny

2

Usamos visualizações quando queremos fazer algo como juntar duas tabelas ou converter valores de código em valores legíveis por humanos. A segunda situação é aquela em que você terminaria com um nome semelhante.

— Beth Whitezel

2

A resposta do Sr. Denny e os seguintes colaboradores são apoiados por isso: dba4life.blogspot.com/2007/11/…

11

@ Mararian: Eu uso plurais porque eles fazem as consultas serem lidas mais naturalmente e resolvem colisões com palavras-chave. Muitos sistemas com os quais trabalhei possuíam uma entidade de pedidos. O uso de plurais faz com que o nome da tabela ordersnão seja ordere evita ter que citar o nome da tabela toda vez que for usuário. Isso também se aplica a groupoutras palavras-chave. Felizmente, poucas palavras-chave colidem com entidades comuns.

— BillThor

13

Usamos esquemas (pense neles como namespaces no SQL, talvez) para permissões e agrupamentos. Então, em vez de "tbl" etc, temos

Data.Thing
Data.ThingHistory
Data.Stuff

Nenhum código entra no esquema de dados. Nenhuma tabela fica fora do esquema de dados. É claro que isso pode ser estendido para que você tenha um esquema de pesquisa ou armazenamento temporário.

Para visualizações que usamos, vwmas isso foi para distingui-las das tabelas no SQL Server 2000 e agora é meio legado

— gbn
fonte

3

+1 para recomendar esquemas. Isso será útil, mantendo um banco de dados grande com centenas de tabelas. Nós usamos esquemas para funcional agrupamento também .. como fez em AdventureWorks db

— CoderHawk

5

Pessoalmente, sou um grande fã do Fanö Bedingung , o que significa que não é permitido que o nome seja o começo de outro nome válido.

E segundo, a distância de Hamming entre dois nomes é melhor do que uma letra diferente.

Sim, são regras desde tempos pré-digitais, mas tornam a vida mais fácil.

E os terceiros nomes devem ser pronunciados, ou você ficará louco quando o reconhecimento de voz se tornar verdadeiro.

— bernd_k
fonte

2

Quando o reconhecimento de voz se tornar verdadeiro, ficarei bravo de qualquer maneira. :-)

— Beth Whitezel

Só se você fizer apoio telethon

— bernd_k

11

Quando o reconhecimento de voz chegar, eu vou me tornar um motorista de caminhão. Isso ou um eremita louco.

— mrdenny

Você poderia explicar com mais detalhes (talvez com um exemplo) o que é "Fano Bedingung"?

— Nick Chammas

11

@NickChammas Acho que em inglês chamamos isso de codificação Shannon-Fano .

— Iain Samuel McLean Elder

2

Não sei se existe realmente alguma "melhor" convenção de nomes por aí, pois ela se resume a preferência pessoal e facilidade de desenvolvimento. Meu conselho é escolher uma convenção de nomenclatura e aderir a ela. Se você deseja separar palavras com um sublinhado, faça-o em todos os seus objetos de banco de dados. Se você deseja usar o camelCase, faça-o em todos os seus objetos de banco de dados.

Na minha loja, seguimos as seguintes regras:

Separamos as palavras com sublinhados e usamos todas as letras minúsculas.
Os nomes de nossas tabelas descrevem o que são: dbo.person, dbo.invoice.
Nossos nomes de tabelas muitos para muitos também descrevem o que são (com a adição de mm para indicar que um relacionamento muitos para muitos está sendo mapeado: dbo.person_mm_address. Nossos procedimentos armazenados definidos pelo usuário descrevem o objeto e a ação que está sendo executada: usp_person_select , usp_address_select_by_city Nossas visualizações e funções seguem as mesmas regras que os procedimentos armazenados.Os nossos índices incluem tabela, colunas-chave (em ordem) e uma indicação de cluster / não clusterizado: ix_person_last_name_first_name_nc

Só porque é isso que usamos em minha loja, não significa que essas regras sejam adequadas para você. Escolha algo que você e sua equipe de desenvolvimento concordem que seja útil e fácil de desenvolver, e estabeleça uma cultura de conhecimento e uso da convenção de nomenclatura que você decidir. No nosso caso, isso inclui a revisão de código para todos os objetos criados em um banco de dados. Com o tempo, a combinação de uma convenção de nomenclatura documentada e revisão de código de pares levou a menos e menos desvios da convenção.

Espero que essa "não resposta" ajude de alguma forma.

— Matt M
fonte

2

Estou contente com isso desde anos atrás

nomes de tabelas: small caps e underscores, singular {customer, product}
nomes de tabela para muitos para muitos relacionamentos: tablename1_tablename2: {customer_product}
visualizações: letras minúsculas adicionadas v ao final {customerv, productv, product_groupv}
procedimentos armazenados: nome e função da tabela {customer_select, customer_insert, customer_delete, customer_update}

se você tiver um pacote de hospedagem compartilhada barato, precisará usar a abreviação do projeto na frente de todos os seus objetos, como, por exemplo, site de administradores de banco de dados, da_users, da_questions

— Uğur Gümüşhan
fonte

Por que product_groupve não product_group_vpara visões (se você insiste nessa distinção de visões e tabelas)?

— ypercubeᵀᴹ

@ypercube porque tenho preguiça de digitar um sublinhado extra e cometo erros de digitação facilmente. Eu leio as palavras com mais facilidade quando uso um sublinhado e uso v para separar a exibição das tabelas, e v não é uma palavra, portanto não uso sublinhado. Parece inconsistente, sim, mas acho esse formato prático.

— Uğur Gümüşhan