Um guia rápido para convenções de nomenclatura em SQL - Parte 1

Nome da tabela

Uma convenção de nomenclatura é um conjunto de regras (escritas ou não) usadas para melhorar a legibilidade de um modelo de dados. Você pode aplicar essas regras ao nomear qualquer coisa em seu banco de dados, incluindo tabelas, colunas, chaves primárias e estrangeiras, procedimentos armazenados, funções, exibições e muito mais. Mas você não precisa aplicar a regra a todos os objetos do banco de dados. Por exemplo, aplique regras de convenção de nomenclatura apenas a nomes de tabelas e colunas. Tudo depende de você, pois usar uma convenção de nomenclatura não é obrigatório, mas ainda tem seus benefícios. Esta série de artigos em três partes apresentará algumas convenções de nomenclatura comumente usadas e explicará algumas dicas para criar suas próprias convenções de nomenclatura. A Parte 1 do artigo abordará os nomes das tabelas, enquanto a Parte 2 se concentrará nos nomes das colunas. Por fim, a Parte 3 apresenta convenções de nomenclatura para outros objetos de banco de dados, como chaves estrangeiras, procedimentos, funções e exibições.

Por que usar uma convenção de nomenclatura

Muito poucos bancos de dados têm apenas um pequeno número de tabelas. E, de fato, não é incomum ter centenas de tabelas. Portanto, seguir a convenção de nomenclatura pode melhorar a legibilidade geral do modelo e facilitar a localização de objetos de banco de dados (DB), ajudando você a realizar o trabalho com facilidade.

Outro bom motivo é que os bancos de dados evoluem lenta e continuamente ao longo do tempo. Embora você geralmente evite alterar o esquema e faça alterações apenas quando necessário, alterar o nome de um objeto de banco de dados pode afetar o código do aplicativo de várias maneiras. Como você pode esperar que o banco de dados permaneça mais ou menos semelhante a como começou, se você seguir as práticas recomendadas desde o início e continuar a usá-las à medida que adiciona novos objetos, a estrutura do banco de dados mudará com o tempo. Mantenha-o bem organizado.

Nomes de tabelas singulares e plurais

Uma das dúvidas mais comuns sobre a nomenclatura de tabelas é se usar formas singulares ou plurais. Existem muitas opiniões diferentes sobre esta questão. Na verdade, podemos ver que os esquemas dos modelos clássicos do MySQL e dos bancos de dados de amostra sakila são nomeados dessas duas maneiras, o primeiro usa nomes de tabela no plural e o último usa nomes no singular:

A maioria dos DBAs usa nomes singulares se isso os ajudar a trabalhar. Uma razão é que nomes plurais como "users", "roles" podem levar a alguns nomes de tabela estranhos como "users_have_roles" em vez de "user_has_role".

Descrever entidades do mundo real

Sempre que você nomear entidades que representam coisas do mundo real, você deve usar seus nomes próprios. Isso se aplica a tabelas como empregado, cliente, cidade, país, etc. Normalmente, uma palavra deve descrever exatamente o que está na tabela.

Às vezes, você precisa usar mais de uma palavra para descrever o conteúdo da tabela. Um exemplo disso pode ser visto no banco de dados classicmodels. Existe uma tabela "orders" e outra tabela "order_details":

tabela de pedidos

detalhes_pedido 表

"order_details" contém dados sobre os produtos encomendados, como a quantidade encomendada e o preço. A tabela pode ser chamada de "product_details", mas isso não indica que o produto está associado a um pedido.

tabela relacionada nomeada

Para um relacionamento entre duas tabelas, é prática padrão usar os nomes das duas tabelas. Também é possível adicionar um verbo entre os dois nomes para descrever qual é a ação, como "user_has_role" ou simplesmente "user_role". O banco de dados de amostra Sakila usa essa convenção para unir tabelas relacionadas com uma tabela intermediária que combina os dois nomes. Podemos ver dois exemplos no modelo de banco de dados abaixo - "film_actor" e "film_category":

Conclusão sobre convenções de nomenclatura de tabelas em SQL

Não tenha medo de desistir de usar uma convenção de nomenclatura se ela não fizer sentido lógico em uma situação específica. Por exemplo, se tivermos uma tabela de produtos e faturas e quisermos especificar quais produtos vão em quais faturas, o nome "invoice_item" pode fazer mais sentido do que "invoice_product" ou "invoice_contains_product".

 revisão anterior 

  1. Navicat premiada Microsoft Gold Partner
  2. Navicat 16.3 suporta oficialmente OceanBase Enterprise Edition
  3. Experimente o Navicat 16 gratuitamente
  4. A história de desenvolvimento de 20 anos da Navicat
  5. A função de WHERE 1=1 na instrução SQL
  6. Calcular a porcentagem do total de linhas no SQL
  7. O evento interativo de presentes está em andamento | O prêmio é o Navicat Premium no valor de 819 yuan
  8. Sites falsos causam vários riscos de segurança | Declaração solene oficial: Não compre ou baixe o software Navicat de canais não oficiais

Acho que você gosta

Origin blog.csdn.net/weixin_53935287/article/details/130125092
Recomendado
Clasificación