Bom, estou com um caso “complicado” aqui. Cá entre nós, eu não sei se é gosto pessoal mas acho tabelas de relacionamento (usergroup x menu, etc) uma coisa feia.
A minha entidade UserGroup possui relacionamento com mais seis tabelas, que são autorizações diversas do sistema para o usuário. E me incomoda a idéia de ter umas 6 tabelas de relacionamento, many to many.
Assim sendo, eu estava pensando no seguinte:
Criar uma tabela chamada authorization, que vai suportar todas as authorizations do usergroup.
AuthorizationId - PK
Authorization_relationtype = Source da autorizacao (ex: menu, como string)
authorization_sourceid = id do objeto (no caso, o id de um menu)
authorization_destination = Destino da autorizacao (ex: usergroup)
authorization_destinationid = id do destino (no caso, usergroup)
Vantagem: escondo essas tabelas de relacionamento e também posso alimentar com N relacionamentos, já que essa tabela nunca será mto grande.
Já precisei usar isso pois eu tinha relacionamentos com 18 tabelas diferentes e ia ter que fazer 18 fors toda vez que fosse usar isso.
Mas eu desaconselho pois você perde a integridade referêncial do banco de dados.
O que significa que o banco deixará você apagar registros relacionados, e que potencialmente fara com que sua aplicação mais tarde de um monte de pau com uns Null Pointer Exception graças a isto.
Se for mesmo usar esse esquema, vc terá que implementar essas validações de referência na mão, o que demora e almenta a complexidade do sistema.
Eu não entendi a questão dos for. Tudo o que eu ia fazer, era acionar o Criteria com Restriction.eq(valorDeUmEnum) e filtrar. Entendo sim sobre a questão de persistencia automatica, etc, mas é que se eu for pensar, nao significa que o meu usergroup tenha uma lista de menus, ele NÃO TEM ISSO, o que ele tem é uma AUTORIZAÇÃO pra usra ou não aquele menu. Foi essa diferença sutil que eu pensei.
