Qual padrão devo seguir ao nomear tabelas e exibiçõ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 outras coisas a fazer/não fazer?
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.
OK, primeiro NUNCA coloque tbl na frente do nome de uma tabela. É uma mesa, já sabemos disso. Isso é chamado de Notação Húngara, e as pessoas pararam de fazer isso há mais de 5 anos.
Basta chamar o objeto com base no que ele é. Se uma tabela contiver dados de funcionários, chame-a de "Empregado". Se ele contém informações sobre computadores, chame-o de "Computador". Se mapear computadores para funcionários, chame-o de "EmployeeComputer" ou "ComputerEmployee" (pessoalmente, gosto mais de "EmployeeComputer").
Não há nenhuma convenção de nomenclatura correta a ser usada (além de não usar a notação húngara). Desde que os nomes dos objetos façam sentido, isso é importante.
Usamos esquemas (pense neles como namespaces em SQL, talvez) para permissões e agrupamento. Então, em vez de "tbl" etc, temos
Nenhum código entra no esquema de dados. Nenhuma tabela fica fora do esquema de dados. Isso pode ser estendido, é claro, para ter um esquema de pesquisa ou teste, se desejar.
Para views usamos,
vwmas isso era para diferenciá-los de tabelas no SQL Server 2000 e é meio legado agoraPessoalmente sou um grande fã do Fanö Bedingung , o que significa aqui que nenhum nome pode ser o início 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 dos tempos pré-digitais, mas facilitam a vida.
E terceiros nomes devem ser pronunciáveis, ou você ficará louco, quando o reconhecimento de voz se tornar verdadeiro.
Não sei se existe realmente uma "melhor" convenção de nomenclatura por aí, pois na verdade se resume à 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 isso em todos os seus objetos de banco de dados. Se você deseja usar camelCase, faça isso em todos os seus objetos de banco de dados.
Na minha loja seguimos as seguintes regras:
Separamos palavras com sublinhados e usamos todas as letras minúsculas.
Nossos nomes de tabela 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 um relacionamento muitos-para-muitos 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 dos procedimentos armazenados. Nossos índices incluem tabela, colunas-chave (em ordem) e uma indicação de agrupado/não agrupado: 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 conhecer e usar qualquer convenção de nomenclatura que você decidir. No nosso caso, isso inclui revisão de código para quaisquer 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 cada vez menos desvios da convenção.
Espero que essa "não resposta" ajude de alguma forma.
Estou contente com isso desde anos atrás
se você tiver um pacote de hospedagem compartilhada barato, precisará usar a abreviatura do projeto na frente de todos os seus objetos, como por exemplo, site de administradores de banco de dados, da_users, da_questions