Convenções oficiais de capitalização do PostgreSQL [fechadas]


14

Existe uma convenção oficial do PostreSQL referente à capitalização em nomes de banco de dados, tabelas e campos?

Os exemplos no site oficial sugerem uma _separação minúscula e de palavras, e me pergunto se essa política é oficial.

CREATE TABLE films (
    code        char(5) CONSTRAINT firstkey PRIMARY KEY,
    title       varchar(40) NOT NULL,
    did         integer NOT NULL,
    date_prod   date,
    kind        varchar(10),
    len         interval hour to minute
);

1
Verifique também esta parte da documentação, sobre identificadores
ypercubeᵀᴹ

Respostas:


20

Basicamente, vou refletir os comentários de Verace e declarar isso, tornando-o semi-oficial:

Não existe uma prática recomendada que cubra todas as circunstâncias. O que segue faz as seguintes suposições (e o que fazer se você não tiver feito isso):

  • Você já discutiu isso com sua equipe (as pessoas que trabalham sozinhas geralmente precisam se decidir)
  • Ainda não há uma definição formal de estilo para SQL em sua equipe (caso contrário, você não estaria nos perguntando)
  • Não há definição formal de estilo para nenhum código (siga as mesmas convenções básicas já estabelecidas para outros idiomas e formalize um estilo)

Portanto, o resto é um pouco opinativo, mas baseado na experiência

  1. Quando se trata de nomes de tabelas
    1. Você deve procurar nomes de entidades singulares (isso facilita a documentação)
    2. Você deve usar o Pascal Case aqui
  2. Quando se trata de nomes de campos
    1. Use camelCase nos nomes dos seus campos
    2. Use nomes curtos no singular, a menos que a definição definitivamente faça sentido como plural (quase nunca)
  3. Quando se trata de sua própria função ou nomes de procedimentos armazenados
    1. Use underscore_separation
    2. Use a nomeação de campos para a parametrização
  4. Quando se trata de funções internas de banco de dados ou nomes de idiomas (por exemplo, SELECT)
    1. A menos que haja um requisito para que seja capitalizado de uma certa maneira, use TODOS OS CAPS
    2. Conheça as APIs do seu idioma para saber o que é razoável ou necessário
  5. Quando se trata de espaçamento
    1. Muitas pessoas usam alinhamento de coluna para palavras-chave e recuo para itens que não são palavras-chave
    2. Muitas pessoas usam vírgulas no início da linha quando os campos são separados em cada linha (isso facilita o comentário de um campo específico de uma lista de seleção)
    3. Nunca use espaços como parte dos nomes das coisas, nem mesmo para cabeçalhos de valor de retorno.
  6. Quando se trata de pontuação
    1. Parênteses - USE-OS. Eles são grátis. Eu prometo.
    2. Ponto e vírgula - USE-OS. Eles não vão te quebrar. Eles o forçam a pensar em seu código. E eles são de boa higiene.
    3. Devoluções de carro - Mais uma vez, elas são gratuitas ;-) E torne seu código legível.

Você também deve reconhecer que, enquanto estou tentando ajudá-lo a aplicar um guia de estilo genérico, a comunidade do Postgres geralmente não usa camelCase ou PascalCase, mas usa underscore_separation. O mais importante é garantir que você estabeleça e use um estilo específico em qualquer lugar para ser consistente .


3
+1 em "O mais importante é garantir que você estabeleça e use um estilo específico em qualquer lugar para ser consistente". Consistência é a chave. Sem ele, você precisa pensar em coisas nas quais nunca deveria pensar.
Max Vernon

4
Bem, camelCase e PascalCase no PostgreSQL são um pouco dolorosos. Você precisa citá-las se realmente quiser ter nomes assim, caso contrário o sistema silenciosamente os colocará em minúsculas (quase escrevi decapitalizar, quaisquer que sejam as associações que possam surgir).
Dez

E os nomes dos bancos de dados? Devo usar database_name, database-name, DatabaseName, databaseName, etc.?
ma11hew28

1
Esta resposta é realmente para o PostgreSQL? Se você der o conselho de usar o PascalCase para nomes de tabelas em uma resposta específica do PG, acho que você deve mencionar (a) como lidar com o fato de que a maioria dos exemplos usa palavras-chave em minúsculas e (b) se deve citar os nomes das tabelas ou deixar PG dobre-os para minúsculas.
AndreKR 16/01

O @AndreKR é o seguinte: espero que os desenvolvedores de software sejam adultos, que saibam ler a documentação e discutam com sua equipe como escrever código de forma consistente. Esta resposta é um wiki da comunidade, o que significa que qualquer pessoa pode editá-lo e melhorá-lo. Não posso dizer exatamente "esse é o único caminho" e apenas porque algumas pessoas dão exemplos todos em letras minúsculas não significa que esse seja o único caminho na vida. Você precisa encontrar seu próprio caminho, que era o espírito dessa resposta. Sinta-se livre para editar esta resposta da comunidade para melhorá-la. Obrigado!
jcolebrand

4

Um rápido Google revelará muitos sites que indicam práticas recomendadas. Eu diria apenas duas coisas - NUNCA use espaços "My Table Name" (a transferência se torna impossível devido a diferentes mecanismos de escape; o mesmo vale para qualquer caractere não alfanumérico). Com esse tipo de mecanismo, você normalmente precisa respeitar também o caso. Existem letras e palavras suficientes no idioma inglês (ou no seu) comprimento do identificador e o comprimento é suficiente (não conheço nenhum sistema que tenha identifier_length <32, o PostgreSQL é 64). E nunca use palavras-chave SQL (que variam de acordo com o RDBMS), que farão a mesma coisa.

Declarações como

SELECT "Field" FROM "Table";

pode ser válido! O absolutamente crítico é ter uma convenção clara e relativamente simples e depois cumpri-la. As pessoas têm opiniões diferentes, como você descobrirá - leia sobre o tópico e escolha o que "parece certo" para você. Veja estes sites 1 , 2 , 3 , 4 , 5 , ... (existem muitos mais).


Obrigado, encontrei muitos em minhas próprias pesquisas. Eu queria saber se existe algum guia de estilo oficial.
precisa

Existem muitos profissionais de ambos os lados do debate (singular_tabela_do_tabela / plural_tabela_do_abelo) cujas opiniões sobre outras áreas eu respeito. Eu sou um homem "solteiro" - se você estiver administrando uma usina nuclear, poderá ter uma tabela chamada catastrophic_meltdown na qual nunca mais deseja ver nenhum registro! Atribua um sufixo às suas chaves primárias _id e se refira a elas como Parent_Table_Name_FK em tabelas filho - é isso que eu faço. Depois disso, é fácil! Quanto a caps / no-caps, meus scripts SQL possuem camel-case (sem aspas), minhas declarações podem ou não.
Vérace 15/06
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.