Olá Genivaldo,
primeiramente, preciso te dizer que a minha experiência com swing é pequena, eu fiz apenas 3 sistemas (conversões de access para java, e de delphi para java).
Basicamente, as situações que mantive o master/details foram em situações que a regra de negócio assegurava que não haveria acesso concorrente a mesma informação ou que a probabilidade de ocorrer seria quase nula. Foram elas:
- cadastro de dependentes e dados de planos de saúde para uma associação;
- cadastros simples de um controle acadêmico
- Sistema de grade horária (esse em andamento).
Estou tendo bastante trabalho na conversão da aplicação delphi para java, principalmente em telas que apresentam quase todos os registros em tabelas e o filtro fosse sendo aplicado de forma incremental (por exemplo, nomes que tenha a palavra josé (com ou sem acento)).
No delphi, utilizando os dataset padrões (ttable ou tquery), qualquer edição de registro implica no lock do registro (master) e dos filhos (detail). Se a aplicação trava ou é fechada, fica a responsabilidade para o BDE ou para o SGBD eliminar os locks. No java, isso tem que ser feito praticamente na mão, ou deixar que o SGBD faça (alto custo).
Para você ter uma idéia da complexidade, em um projeto com alta concorrência, tivemos que manter duas instâncias do registro alvo, e antes de aplicar as alterações, consultar o mesmo registro usando uma transação serializada para poder efetivar as alterações… caso o mesmo campo tivesse sido modificado, o registro voltava para o usuário fazer a reconfirmação.
Com relação a sugestão de telas, eu faço duas recomendações:
- Se é um caso similar aos citados acima, sem problemas - eu normalmente uso o jtable mesmo
- Se a idéia é apresentar uma tabela com alguns dados inicial para que o usuário possa iniciar as operações, tende criar uma restrição temporal, como no caso de uma agenda - retornar apenas os dados do dia, da semana ou eventualmente do mês. Nestes casos, evitar a edição direta na tabela, uma vez que a permanência da informação na tela pode ser muito longa e ela pode sofrer alterações concorrentes. Logo, se você escolheu um registro de um jtable que será editado em uma segunda tela (ou panel), faça uma nova pesquisa desse dado. Isso aumentará o uso do banco, mas o resultado será mais confiável.
- A maior parte dos bancos, permitem limitar o número de linhas das querys (algo como o top do oracle, ou limit do mysql/postgres), isso facilita bastante a criação de sistemas de paginação. Te garanto que ninguém lê as informações de uma tabela com mais de 50 ou 100 linhas…
Outra coisa, vamos supor que você faça a carga de 300.000 registros de clientes (300.000 objetos pojos desses clientes), quando você apresentar alguns dados destes no jtable, por exemplo números e datas, estes serão “convertidos” para String, então o seu heap vai aumentar um monte, começará a exigir mais memória para a sua aplicação e mais do gc.
Eu ainda não consegui chegar a nenhuma fórmula mágica sobre essa questão, na minha aplicação atual, tenho um “grid” que apresenta aproximadamente 1.000 registros. Mas ela pode crescer exponencialmente (grade horária) (período x turma x aula ).
espero que te ajude.
fw