Tenho uma entidade “Pedido” que irá possuir dois estado, “Em Aberto” ou “Fechado”.
Pensei em fazer outra entidade chamada “Situação” contendo um int “id” e uma String “nome”, depois persistir as duas instancias delas em banco e dependendo da situação associá-la a pedido quando fosse necessário.
Acho que há uma formar mais simples e correta de se fazer isso, apenas não sei como. Alguém tem uma idéia?
Na minha opinião não precisa complicar. Se os status serão apenas estes, no BD crie apenas uma coluna chamada “situação” na mesma tabela de Pedidos. No Java você pode utilizar Enums para os status. Situação será apenas um atributo da entidade Pedido.
Exatamente. Não precisa criar uma nova tabela para armazenar só dois registros. Armazenando na mesma tabela você evita ter que fazer joins sempre que for recuperar a Situação.
Abs,
Olha Victor, você pode até fazer isso, mas você tem que pensar na complexidade que isso vai gerar, você vai precisar manter mais uma entidade, vai ter que fazer mais acessos ao BD para recuperar essa informação, se você for pensar bem não seria viável sua solução, e sim fazer como nossos amigos sugeriam, criar apenas mais uma coluna na sua tabela que grave a situação atual do seu registro, somente isso basta para atender sua necessidade, e vai deixar sua aplicação mais performática
Att
Bom, sou um defensor da normalização em banco de dados relacionais - visto que é mais custoso um scan sobre strings do que fazer um join a mais. Obviamente, considerando um sistema onde a volumetria dos dados da tabela tendem a crescer bastante; neste caso, considere pesquisas como “pedidos em aberto”, “pedidos fechados”, etc. sem contar a flexibilidade de adicionar novas situações, acreditem, vai acontecer.
É apenas uma opinião diferente para ser analisada.
[]s
Como o dado possui apenas dois estados, cria um boolean para PEDIDO_ABERTO, se for true, esta aberto, do caso contrario, esta fechado. Desse modo não existe a necessidade de uma nova tabela ou uma Enum.
[quote=peerless]Bom, sou um defensor da normalização em banco de dados relacionais - visto que é mais custoso um scan sobre strings do que fazer um join a mais. Obviamente, considerando um sistema onde a volumetria dos dados da tabela tendem a crescer bastante; neste caso, considere pesquisas como “pedidos em aberto”, “pedidos fechados”, etc. sem contar a flexibilidade de adicionar novas situações, acreditem, vai acontecer.
É apenas uma opinião diferente para ser analisada.
[]s[/quote]
Não acho que seja necessário fazer isso, se acontecer de aparecer novos status dos pedidos, ele pode manter isso em um Enum, evitando assim a criação de tabela e possivelmente tela de CRUD para manter essa tabela, sem falar que não vai precisar fazer JOIN com tabela nenhuma, tornando a consulta mais rápida.
Realmente a normalização é um fundamento muito bom da nossa área, mas acho que tem casos e casos de se usar, e também tem que analisar até que nível de normalização você quer chegar, 4, 5…11ª forma normal
Att
Boa noite a todos.
[quote=peerless]Bom, sou um defensor da normalização em banco de dados relacionais - visto que é mais custoso um scan sobre strings do que fazer um join a mais. Obviamente, considerando um sistema onde a volumetria dos dados da tabela tendem a crescer bastante; neste caso, considere pesquisas como “pedidos em aberto”, “pedidos fechados”, etc. sem contar a flexibilidade de adicionar novas situações, acreditem, vai acontecer.
É apenas uma opinião diferente para ser analisada.
[]s[/quote]
Eu estou com a maioria e não abro.
Não há nada que uma instrução SQL não resolva, além disso, se voce acha que um scan sobre strings é mais custoso do que um efetuar um join, então imagino eu que voce esteja pessando em busca sequencial (varredura registro a registro), cuja inplementação não se usa mais, e já está obsoleto faz tempo, pois a sintaxe “Select” consegue efetuar um filtro em 1.000.000 registros em pouco menos de 30 nanosegundos.
Ainda sim, se o string custa mais a ser filtrado, então pode se usar o campo situação com numérico ou até booleano como foi sugerido.
Para que complicar, se esta dica simples resolve todo o problema, e lembre-se, quanto mais simples a aplicação melhor, porque fica menor para ser interpretada, consome menos memória e a performance fica mais dinâmica e rápida e bastante funcional, até mesmo para documentar o projeto.
DEUS criou o Universo através de uma singularidade que gerou o Big Bang e criou todo este universo complexo.
Não estou olhando para o caso em específico onde, se houver um novo estado háverá, provavelmente, necessidade de nova implementação, porém não creio que o enum seja a melhor solução para representar um estado armazenado no banco de dados, pois caso seja necessário um novo estado, obriga-se a necessidade de manutenção do código apenas para adicionar esse novo estado no enum. Isso sem contar que obrigatoriamente, esse enum estaria engessado à base de dados definitivamente (e isso teria que estar devidamente documentado).
Se houver uns 99% de certeza de que um novo estado não vai surgir, concordo com a criação de um campo novo na tabela e algo mapeando os estados.
Caso contrário, é interessante pensar sim numa tabela de estados que estaria disponível para todo o sistema e não apenas para uma tabela em específico.