Dúvidas de modelagem em Grails
29/08/2011 21:35
1
Olá, pessoal!

Estou com uma dúvida...

Preciso implantar um sistema de controle de cadastros e ativos (telefonia celular) onde o mesmo servirá para cadastrar informações de clientes distintos. Escolhi o Grails para me ajudar nessa tarefa. :-)

Partindo de uma visão comum, todos os clientes tem informações que se repetem, como número da linha, tipo de aparelho, centro de custo, nome do usuário, superior imediato etc... Sendo que cada cliente tem informações muito específicas que outros não tem, como: região, estado, código de setor etc... Sem contar a forma como se define a estrutura de hierarquia (alguns clientes se dariam bem com uma solução de auto-relacionamento das chaves primárias, já outros seriam associando um chefe para cada setor etc...)

De posse dessa complexidade, qual seria o melhor caminho a seguir para poder tirar o máximo de aproveitamento do Grails? Na minha cabeça seria partindo de uma herança. Eu teria uma entidade "Cliente" e a partir disso outras entidades que a herdariam, tipo: "ClienteMacDonalds". Mas e para solucionar o problema de hierarquia? Já q cada cliente tem uma forma distinta de definir um superior imediato?

Bom... Não sei se me fiz claro, mas realmente estou com essa dificuldade de qual caminho seguir. Sei que abusar de herança não é algo muito elegante e nem muito produtivo... E não sei como isso implicaria no engine do Grails na hora de gerar as views e controladores dinamicamente.

Muito obrigado!
Tags: modelagem, GORM, herança, UML, dúvida Grails, domínio


0
Oi Carlos, bacana a discussão. Rola de você adicionar mais detalhes sobre o seu problema? Quanto mais informações sobre o seu problema, melhor.

Você tem de levar em consideração alguns fatores importantes: no caso de estar usando herança, qual estratégia seria a mais adequada? Uma única tabela para toda a hierarquia ou uma tabela por entidade?

No caso de uma tabela para toda a hierarquia, você vai ter como problema o fato de ter de definir como anuláveis basicamente todas as colunas que são específicas para um tipo único. Além disto, caso a base de dados cresça demais, também vai ter problemas com a performance do banco no futuro.

Por outro lado, uma tabela para cada subtipo também é trabalhoso, porque você precisará dar manutenção em mais de um ponto.

No final das contas, acaba que a solução acaba sendo a mais batida de todas: meio termo mesmo.


Com o passar do tempo, no entanto, eu venho observado em mim uma necessidade cada vez maior de sair do modelo relacional. Será que não poderia ser o seu caso? Tenho uma regra geral pra isto: se há uma tabela com dados esparsos, isto é, com colunas cujos valores são raramente preenchidos, já tenho um candidato a uma abordagem noSQL.


0
Obrigado, Kiko!

O meu problema é que tenho entidades com 70% de atributos iguais e 30% de atributos e regras específicos, por exemplo:
-----------------------------------
class ClienteMcDonalds

String numeroDaLinha
String tipoAparelho
String nomeUsuario
String centroDeCusto
Cliente McDonalds superiorImediato
------------------------------------
class ClienteBOBs

String numeroDaLinha
String tipoAparelho
String nomeUsuario
String cargo
int setor
String região

Conforme pode ver, apesar das entidades compartilharem os mesmos atributos, outros são específicos para cada uma delas. Sendo que no ClienteBOBs a hierarquia é definida pelo nome do cargo. Já no ClienteMcDonalds é dada pelo atributo “superiorImediato” (um auto-relacionamento). No meu sistema tenho mais umas 5 classes com problemas similares: Compartilham alguns atributos mas tem alguns outros específicos.

Esse seria um caso de migrar para uma solução noSql? Se sim, como o Grails lida com isso (GORM)? Como isso afeta a produtividade que o Grails fornece ao se trabalhar com bancos relacionais? (scaffold dinâmico, etc...)

Muito obrigado mais uma vez! :-)
01/09/2011 08:14


0
Oi Carlos,

nah, neste caso não compensa algo NoSQL. Se você usar uma abordagem usando herança e GORM mesmo já resolve seu problema bem.

Da uma olhada neste link: http://grails.org/doc/latest/guide/5.%20Object%20Relational%20Mapping%20(GORM).html#5.2.3%20Inheritance%20in%20GORM


0
Entendi.

Pensei que, como a massa de dados a ser analisada pela aplicação é muito grande (faturamento de telefonia celular), talvez uma abordagem baseada em herança não fosse a melhor alternativa, já que os requisitos mudam de cliente para cliente.

Aproveitando a discussão, vou abrir um post no fórum para falarmos sobre ferramentas noSql em Grails. Espero que renda boas discussões!

Obrigado!
01/09/2011 15:14


0
Oi Carlos,

eu acredito que no futuro, nesta situação que você está descrevendo, para as tarefas mais "hard-core", vocês vão acabar deixando o GORM de lado e trabalhar diretamente com consultas SQL, porque assim vão ter um poder de tunagem bem melhor.

Quando lidamos com qualquer ORM, não há muito como fugir da seguinte realidade: ele sempre vai te atender 90%. Pros outros 10, não tem jeito: você TEM de sujar as mãos no SQL bruto mesmo.



Ainda não faz parte da comunidade???

Para se registrar, clique aqui.


Aprenda Groovy e Grails com a Formação itexto!

Newsletter Semana Groovy

Assinar

Envie seu link!


Livro de Grails


/dev/All

Os melhores blogs de TI (e em português) em um único lugar!

 
Creative Commons
RSS Grails Brasil é mantido por itexto Consultoria.
Em caso de problemas contacte Henrique Lobo Weissmann (Kico) por e-mail: kico@itexto.com.br
Todo o conteúdo presente neste site adota o Creative Commons como licença padrão.
Ver: 4.14.0
itexto