Como voces costumam salvar STATUS no banco de dados pra ler em uma aplicação?
Atualmente tenho algo como:
waiting
in_queue
error
closed
success
Mas estou pensando em alterar para números (me parece mais organizado), então ficaria algo como:
1 = waiting
2 = in_queue
3 = error
4 = closed
5 = success
Como voces costumam fazer?
Como sempre: DEPENDE.
Qual o tamanho da tabela que usa esse status? Ela vai crescer, ou vai permanecer relativemente pequena? A númeração que você pretende dar ao status tem sentido com a ordem desses status? Podem surgir novos status ao longo do tempo?
Eu uso geralmente como string mesmo por ser mais fácil de entender quando se lê o banco de dados diretamente, e até hoje não tive problemas, mas a tabela em questão tem algumas centenas ou milhares de registros apenas. Se eu fosse fazer para uma tabela na casa de dezenas ou centenas de milhares de registros, eu já pensaria em usar numeros a fim de otimizar.
Geralmente se usa números mesmo. Se não for isso vai usar o que? Texto? Isso pode até ferir a normalização no sentido geral.
A questão é só como vai vincular esses números. Pode até ser informação, pode ter com uma tabela auxiliar, ou pode ser usando uma enumeração nativa do DB.
Não é questão de espaço ou de performance, é semântica. Só deve jogar fora a semântica certa se outros fatores forem muito importantes. Em sistemas complexos não pode fazer sem considerar isso. Em sistemas simsples não precia se preocupar, qualquer coisa vai dar certo.
Veja mais para entender porque é necessário fazer organizado.
Observou? Faz sentido para você?
Espero ter ajudado. Em geral estou à disposição na plataforma (sem abusos :D)
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).
usei muito flags numéricas ao longo da vida. agora uso tags. normalização estrita sem exceções era necessário em tempos que não havia espaço em disco. para coisas simples como status, uma string me parece muito adequado.
um join a menos e visibilidade instantânea sem dicionário de dados para um novo integrante.
não estou amassando normalização em bancos relacionais depois de tantos anos. só cansei de algumas regrinhas pouco úteis, pouco vantajosas.
Quem bom que serve para você em projetos simples de poucas mudanças. Quando pegar outros tipos de projeto vai ver o rolo que é isso.
Se é para rolar xadrez de pombo, então vamos lá.
ah, maniera um pouco. é só uma flag. ninguém vai morrer.
a sua suposição sobre os meus projetos não tem fundamento.
Eu diria que depende do tipo de banco de dados que você irá usar. Se tiver algum tipo que represente isso de forma estrita é bacana de usar para manter consistência no BD. No MySQL por exemplo eu sei que existe o tipo ENUM que você poderia utilizar:
ENUM('waiting','in_queue','error','closed','success')
O ponto negativo de usar em inteiro é que se isso não for bem documentado (não somente no momento da criação, mas posteriormente, caso seja adicionado algum novo status) pode acabar se tornando um magic number.
Eu tambem iria de Enum , uso drizzle ou Prisma nos meus projetos e sempre uso enum para Roles e Status.
minha visão sobre enums do mysql. eu não uso mais.
Não acho que seja um problema manter como texto, se for padronizado, facilita o entendimento. Mas uma abordagem interessante, é nessa tabela definir todos como númericos, como no seu exemplo, e criar uma tabela a parte que contenha a "legenda" desses números, mostrando o que cada um deles significa. Assim, se precisar ter a informação em texto, apenas um JOIN é suficiente para te atender.
Eu uso inteiros e adiciono algum tipo de cometario na ddl ou algo assim
os enums eu uso se a lang que eu tiver usando tiver suporte de declarar enums a partir do inteiro
Algumas execessoes pra orms como django-orm que cc cria um tipo enum e usa como option de um campo e ele gera da melhor forma que o SDB preferir.
No mais uso postgres pra tudo e prefiro manter inteiros e ponto
Menos é mais
como é algo q n muda muito mas se mudar é facil basta um insert sem falar que da pra indexar de forma tranquila