Melhor abordagem pra esse tipo de problema com banco de dados

Depende do caso. Se a tabela não crescer muito, eu uso enums para isso.

mas vc deixa isso estatico? nao carrega do banco na hora de utilizar?

Como eu disse, depende do caso. Como as aplicações que eu desenvolvo são basicamente SaaS com um número alto de requests, eu tendo a diminuir o número de joins para evitar usar um overhead desnecessário no banco. Então, dependendo do caso, eu faço apenas o select do id e obtenho as informações restantes pelo construtor implícito do enum.

tipo isso:

public enum TipoPerfume {
  
  int id;

  public int getId(){return id};

  PERFUME_FEM {
    id = 1;
  }, 
  
  PERFUME_MAS {
    id = 2;
  }

}

Com Enums isso vai ficar muito estático, hard-coded.
Se caso aparecer mais um tipo diferente, vc vai ter que gerar outra versão pro cliente?
Se eu fosse voce, faria uma tabela no banco, com isso, alem das vantagens de ser dinâmico, vc pode fazer relatorios como por exemplo qual tipo é mais vendido.

igor_ks:

Com Enums isso vai ficar muito estático, hard-coded.
Se caso aparecer mais um tipo diferente, vc vai ter que gerar outra versão pro cliente?
Se eu fosse voce, faria uma tabela no banco, com isso, alem das vantagens de ser dinâmico, vc pode fazer relatorios como por exemplo qual tipo é mais vendido.

Sim sim… ja existe uma tabela no banco.
A pergunta é: qual é a melhor abordagem? Criar uma classe por tabela? Ou o que?

Se já existe uma tabela, crie uma entidade pra ela entao, com id e descrição.

A abordagem dos Enums eu também uso, mas para domínios estáticos da Aplicação, onde você sabe que eles não irão mudar e se mudarem, você terá que alterar sua app de qualquer jeito. Algumas outras coisas tbm poderiam desde sempre ser usadas como enums como Estado Civil, Sexo, etc.

Se seus tipos de perfumes forem mudar com frequencia, use a tabela mesmo, se a frequencia de alterações for quase nula ou nula, simplesmente use os Enums, eles vão tirar o overhead do seu BD (claro, onde isso for realmente importante).

Abs []