Executando verificação de segurança...
Em resposta a [Não disponível]
1
cyp

Mais uma postagem do estilo "Religião da programação" aqui.

Sempre a ideia de "boas práticas", "faça isso, não faça aquilo", e sempre o motivo dessa defesa é "porque deu certo comigo".

Cada caso é um caso. Seu caso não se aplica para todos os outros.

Eu conheço sistemas legado que o banco de dados é gigante, as TABELAS_SAO_ESCRITAS_ASSIM, as colunas também, e ele funciona muito bem. Sempre novas modificações, atualizações, seguem a convenção do projeto.

Convenção, nomenclatura, design pattern, tudo isso deve ser estudado no início do projeto, e averiguar a melhor que se encaixa naquela situação. Não existe linguagem, padrão, "boa prática", nomenclatura, e etc... para qualquer coisa.

Carregando publicação patrocinada...
1
dataClaudio

Concordo perfeitamente contigo que a convenção deve ser definida no início do projeto e este é o nosso caso tá?
Não estamos buscando uma bíblia que defina as regras e quem não seguir vai para o inferno, longe disso.

Como mesmo citou, já trabalhamos em diversos tipos de banco de dados e cada um tinha uma forma diferente de organização, mas quando se gerencia um time e precisa definir a convensão de um projeto, pode ser uma boa prática pegar um pouco de bom de cada lugar, e esse post tem aqui essa intenção.

O que você viu de bom em outros ambientes e que VOCÊ gostaria de replicar em novos projetos?

1
cyp
Autor
Autor

Entendo seu ponto.

Pela postagem, dava a impressão que era uma regra para todos os tipos de projeto. Me perdoe se lhe interpretei mal, mas foi este meu entendimento.

Acredito muito que o banco de dados deve seguir a terminologia da tecnologia que vai manipular ele. Vai mexer com PHP? snake_case_combina_bem. C#? PodeUsarPascalCase, o que já é padrão no Entity Framework. Javascript? vaiDeCamelCase.

Essa é só um ponto que eu acho ser relevante na hora de decidir a nomenclatura, mas não é uma regra. Claro que podem haver exceções e o time sugerir algo que faça mais sentido.

O importante é todos estarem de acordo com isso.

1
dataClaudio

Obrigado pela contribuição Cyber,

Inicialmente escolhemos o snake_case pois tivemos algumas dificuldades com letras maiusculas em algumas ferramentas como o DBeaver usando o Postgres, faz todo sentido com a sua pontuação em relação a linguagem.