Fala pessoal, tudo bem? Hoje eu tenho um sistema (Java Desktop) que é utilizado em portaria de condomínios,
O sistema já está bem avançado e já tenho alguns clientes, mas uma coisa que eu não consigo pensar em como fazer é vincular os moradores cadastrados, exemplo:
Eu quero cadastrar o filho do Fulano de Tal, mas na minha tabela vão ficar dois cadastros do Bloco A, Apto 18…
Meu cadastro atualmente está assim:
Alguém pode dar alguma ideia de como eu consigo o morador B, C e D com o morador A?
Não sei se ficou muito claro, então vou explicar melhor aqui…
Eu tenho o morador João da Silva, porém o João tem 2 filhos e 1 esposa, eles são dependentes do João.
Eu posso até fazer tudo em uma tela de cadastro só… MAS, quando eu vou cadastrar uma encomenda, o nome do destinatário pode vir em qualquer nome de uma pessoa que more naquela unidade…
Aí na hora que eu quero cadastrar, eu não tô sabendo pensar num jeito que pegaria todos esses dependentes…
Se o melhor jeito é fazer uma tabela (banco de dados) separada, ou deixar tudo em uma tabela só
Não sei se entendi seu problema. Mas no geral poderia ter as tabelas: bloco, apartamento (fk bloco), morador e mais uma tabela de relacionamento n x n (morador_apartamento).
Na sua tabela Morador você poderia ter uma coluna com o id do pai e outra com o id da mãe, assim consegue relacionar moradores filhos com moradores pais.
Acabei me expressando mal mesmo, mas resumindo bem: uma unidade (bloco/apto) pode ter 15 pessoas morando, mas também pode ter uma outra unidade que more apenas duas pessoas. (era mais facil ter explicado assim kkkkkk)
Entendi! Aí na hora de pesquisar, ele me lista todos os moradores daquela unidade… Eu só não sei se faço o correto hoje, quando você tem um FK, é necessário fazer o INNER JOIN? Eu sempre utilizo, mas não sei se é certo fazer isso…
Depende. No seu caso deve precisar de joins entre as tabelas bloco, apartamento, morador e morador_apartamento.
Entendi. Mas isso em tabelas separadas? Atualmente todos os moradores estão na table moradores
Basicamente a table é composta por
id, nome, bloco, apto, telefone.....
O que faz mostrar TODOS os moradores na minha JTable, eu posso até usar o DISTINCT na busca, mas o DISTINCT não vai me retornar o mesmo usuário sempre…
Então se eu tiver 15 moradores na unidade A18, vai me retornar os 15, e só retornando no DISTINCT, a cada busca, ele vai mudar o nome da pessoa que está na unidade…
Utilizar o conceito de grupo e sub grupo não atenderia de uma forma legal?
Grupo
Sub grupo 1
Sub grupo 2
Imagino que ficaria algo como:
Bloco 1
Apartamento 1
Morador 1
Morador 2
Apartamento 2
Morador 1
Morador 2
Morador 3
Bloco 2
Apartamento 1
Morador 1
Nesse formato, partindo de bloco e apartamento você terá todos os moradores que ali residem.
Não, o id_pai e o id_mae seriam FKs para a própria tabela moradores.
Vou testar aqui guys, obrigado pelas sugestoes!!
Na sua tabela moradores poderia ter uma coluna chamada subordinante.
Escolhi esta palavra porque subordinante seria aquele que possui subordinados, mas o ideal é encontrar uma palavra melhor pra descrever o relacionamento em o titular e seus dependentes.
O fato é que se o valor da coluna subordinante for null, quer dizer que ele não é subordinado (ou dependente) de ninguem, logo ele é o titular (o responsavel por aquela unidade).
Se uma pessoa é dependente de alguem, nesta coluna deverá estar o id do titular da unidade.
Dessa forma vc poderia pegar todos os moradores de uma certa unidade ou pegar apenas o titular acrescentando um “where moradores.subordinantes = null” ou algo equivalente.
Outra ideia é acrescentar a coluna tipo à tabela moradores. O tipo poderia ser “titular” ou “dependente”.
Aí teria uma outra tabela chamada titular_depedente que faria a relação entre titulares e seus dependentes.
Esta ideia permitiria que uma unidade tivesse mais de um titular, mas ficaria mais chato pra gerenciar os dependentes, já que poderia ter uma situação em que o marido e a mulher são titulares, mas os filhos só estão relacionados como dependentes do marido.
desculpa nao poder ajudar mas fiquei interessado… como conseguiu esse visual? usando java FX ou o swing mesmo? (talvez algum outro, fiquei interessado, adoraria aprender sobre 
).
Seguindo a ideia do @Jonathan_Medeiros, utilizaria a tabela de moradores e outra com o relacionamento de moradores_blocos_apartamentos. Na tela de cadastro utilizaria um checkbox para identificar o responsável pelo apartamento, daí, poderia ter mais de um responsável vinculado ao apartamento.
Existem momentos em que o modelo relacional deixa a coisa engessada.
Em NoSQL Grafo você terá uma liberdade tal pra lidar com isso e uma flexibilidade que alem de controlar os dependentes poderá controlar tambem os amigos dos dependentes, por onde eles andam dentro do condominio, horarios de maior fluxo entre outras coisas simples de gerenciar.
Ah !! mas tudo isso dá pra fazer no modelo relacional, claro que dá, mas o problema é quando precisa colocar outros controles.
Primeiramente, obrigado a todos por responderem e por darem uma dica.
Eu fiz de duas formas:
1ª:
Mantive a minha tabela morador e criei uma segunda: morador_familiares.
id_morador é FK com o id da tabela morador…, nesse modelo eu consegui recuperar os dados, mas se eu faço só o INNER JOIN, ele me retorna tudo na mesma linha:
E quando eu tento pegar isso no Java:
conecta.executaSQL("SELECT * FROM morador \n"
+ "INNER JOIN morador_familiares \n"
+ "ON morador.id = morador_familiares.id_morador");
if (conecta.rs.first()) {
do {
System.out.println(conecta.rs.getString("nome"));
} while (conecta.rs.next());
}
Ele só me retorna um nome.
Pra pegar os outros dados, eu preciso fazer isso:
SELECT morador.telefone, morador_familiares.telefone
AS telefone2, morador.nome, morador_familiares.nome AS nome2
FROM morador
INNER JOIN morador_familiares
ON morador.id = morador_familiares.id_morador
ORDER BY morador.id
Mas isso vai me custar muito tempo…
2ª forma:
fiz isso:
Onde eu consigo retornar apenas os titulares de uma determinada unidade, a coluna é do tipo boolean, e se for true é títular, se false, não é…
Boa tarde! Utilizei o Java Swing, ainda não consegui pegar bem o FX, eu tenho um canal no YT e posto alguns vídeos (não sou frequente lá)
https://www.youtube.com/channel/UCLPH9Q0iWmk8S_PzLpSDcEw.
Fala @j-menezes, isso eu já consigo gerenciar tranquilo, meu maior problema mesmo estava na hora de separar esses “dependentes”, mas obrigado pela dica!
Estou visualizando outra situação: Se chega uma correspondência para uma pessoa e o(a) porteiro(a) não sabe de qual apartamento e bloco esta pessoa é e se é morador ou dependente. Como está utilizando duas tabelas a pesquisa fica mais complexa.
Então… É que eu sou meio fraco de SQL, mas o INNER JOIN traria esses dados. Pra cadastrar uma encomenda eu faço:
Porteiro escolhe bloco/apto, aparece os moradores dessa unidade, aí já é mais tranquilo
