Executando verificação de segurança...
1

Como voces nomeiam as colunas das tabelas no projeto? com prefixo ou sem prefixo, qual a melhor forma?

Recentemente eu estive com uma dúvida, trabalho há 1 ano como dev júnior com Laravel e para fazer as tabelas usamos as migrations que geralmente contêm colunas dessa forma:

$table->string('nome');

só que eu vi outros projetos aqui da empresa em que utilizavam dessa forma para uma tabela chamada Pessoas

$table->string('pes_nome');

Com o prefixo "pes" no nome da coluna para referenciar à tabela pessoa.
Minha dúvida é: é uma questão de gosto pessoal ou existe alguma explicação técnica para se usar um prefixo no nome da coluna? Pois geralmente quando vejo nas aulas e em outros projetos, nunca usam dessa forma, e eu achei bastante interessante e bem organizado. Pode ser algo bobo, mas gostaria de mais explicações.

Carregando publicação patrocinada...
2

Vamos dizer que seu sobrenome seja Souza. Quando você vai colocar seu nome você coloca Hercilio Souza, ou SouHercilio Souza?

Se a pessoa precisa fazer isso tem algo muito errado em todo o processo de desenvolvimento dela. Ela usa isso para compensar uma decisão errada que tomou em outra coisa.

De qualquer forma, se adotar isso deve manter a consistência. Se a empresa faz assim, vai ter que fazer assim. Ou convencer todo mundo a mudar e reescrever em todos os lugares do jeito mais adequado.

Entenda que a maioria das pessoas fazem coisas que ouviram dizer que é assim, que viram alguém fazendo e fizeram igual, em geral elas não conseguem justificar porque fizeram ou a justificativa é justamente para consertar um erro cometido antes, que era melhor não ter cometido. Em alguns casos a justificativa pode ser que teoricamente poderia digitar menos (péssima, mas ela existe), o que nem sempre se comprova. Então eu nem sei se é gosto, porque gosto você não precisa justificar, só diz que é.

Ser redundante não é organização. A não ser que exija isso, o que não costuma ser o caso, exceto pelo que eu falei, outra decisão ruim obriga fazer isso. Mas não é algo que vai implodir o mundo se fizer, por isso tanta gente faz. As pessoas param quando elas têm problemas sérios, os pequenos elas vão colecionando. Programar é se expressar, tem várias maneiras de fazê-lo, algumas melhores do que outras, algumas permitem ser melhor compreendido do que outras, mas se houve a compressão está ok. Só não chame de melhor.

Veja mais: https://www.tabnews.com.br/maniero/b051826e-56db-4fcb-ab1b-16ab55becfb1.

Faz sentido para você?

Espero ter ajudado.


Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

1
1

Seu comentário é perfeito.
Quando você olha para um atributo, dificilmente o fará sem um contexto envolvido. E o contexto lhe permite cortar redundâncias. A comunidade Go costuma seguir esses preceitos, doutrinados desde a documentação de sua standard library, e eu acho lindo.

Imagine que você está em um escritório em que todas as portas têm uma pintura com seu nome:

porta sanitários
porta saída de incêndio
porta cozinha
porta sala de reunião

Quando você olha para a porta, está claro que se trata de uma porta. A nomenclatura escolhida se torna redundante, verborrágica e pouco significativa.

O exemplo é bem elementar para deixar claro quão ruim é uma escolha de nomenclaturas verborrágicas e redundantes.

Eu tenho PAVOR de nomes complexos que pouco dizem. Cheguei a trabalhar em empresa cujos nomes dos atributos de banco continham siglas do domínio do negócio, tipo do campo e nome da tabela! Sobrava pouco espaço para dar o maldito nome necessário, pois além, de tudo isso havia limitação de 25 caracteres.

Dar um nome a algo em programação é muito mais do que somente seguir determinados padrões, apesar de ser relevante. É muito mais importante. Dar um nome é tentar dizer algo da forma mais imediata o possível para quem vai ler e usar. Se houver a necessidade de se pensar demais para entender o que significa um nome, todos sofrem desnecessariamente.

Nunca se esqueça: contexto. Leve isso pra tudo em programação. Não somente para nomes de campos em tabelas. Uma variável pode se chamar "a" se estiver dentro de um escopo de função com somente outras 2 ou 3 variáveis. Escopos permitem nomes simples. Variáveis globais ou em escopos muito populosos precisam ser mais descritivas.

1

Eu utilizo sempre os nomes sem prefixo, uma vez que na chamada sempre vai ser direta do model, já vai ser diretamente Peoples e o nome da coluna por exemplo.

Só uma coisa que mudaria no seu exemplo, é o nome das colunas sempre em inglês.

1

Na empresa onde você trabalha pode haver uma convenção de nomes que deve ser adotada para as tabelas do banco de dados.

Por exemplo, em projetos onde trabalho, as tabelas sempre começam com tb_, views com vw_, e as colunas usam prefixo de acordo com o tipo de dados: cd_ para chaves únicas que não sejam a chave primária, id_ para as chaves primárias, txt_ para texto em geral, num_ para número, in_ para booleano (acho que está relacionado à palavra indicador) e assim por diante.

A convenção é adotada no início do projeto e geralmente está documentada, então a razão de sua empresa seguir essa nomenclatura pode estar baseada numa convenção.

Em projetos particulares e freelas que atuo, não costumo empregar essas coisas, pois procuro sempre deixar o nome dos campos os mais próximos do mundo real, e também uso sempre o inglês. Mas isso acho que está relacionado mais ao meu gosto pessoal e quando se trabalha em um projeto grande, seu gosto pessoal precisa ser deixado de lado :)

1
1

Ao nomear um campo, só tenha em mente que um campo pode ser ambíguo.
Por exemplo, descricao
É algo muito genérico.
Descrição do quê?
Da categoria? Da empresa?
Prefixo ajudaria a resolver essa questão de forma automatica.
ctg_descricao, emp_descricao
Também poderia abrir mão de prefixo, mas teria que ficar sempre atento a campos genéricos e incluir a tabela, o assunto a qual a informação pertence:
descricao_categoria, descricao_empresa... categoria_descricao, empresa_descricao... categoria_dsc, empresa_dsc...
Como disseram, primeiro seguir a regra da empresa, senão existe sugiro o que eu falei.

1

Um campo não precisa ser um universo numa casca de noz. É só um campo, e quase sempre será usado dentro de contextos. Portanto, na minha opinião, tentar dizer mais coisas dentro dele do que de fato ele é torna-se redudante. Overhead cognitivo.