Rede social em jsp

Você se refere à modelagem do banco de dados?
Crie uma tabela associativa entre usuario e amigo, contendo uma flag que indique status (0 pedido de amizade, 1 amigo, 2 recusado) por exemplo.

Cara… depende, estás usando Modelo Relacional ???

Achas mesmo que é uma boa idéia fazeres uma Rede Social em JSP ??? Só tens essa opção ??

Att.

Galera, é um banco de dados relacional, estou modelando usando o mysqlWorkbench , por ser um trabalho de faculdade estou usando jsp pra ganhar nota, depois vou remodelá-lo em jsf…

Tabela Pessoa
->Id Pessoa
Nome

1

Tabela Amigos
->Id Pessoa
->Id Amigo (no fundo é outro Id Pessoa)
Situação (1 Amigo, 2-FAmilia, 3- Namorado, 4 inimigo, 5 amizade colorida, etc…)
Estado A Ativo, P Pendente, C Cancelado

sei lá, acho que pode ser assim.

Forreta , eu estava pensando em fazer mais ou menos deste jeito mesmo, mas alguma idéia pessoal, alguém já fez alguma rede social alguma vez??

wellington.nogueira:

Pensando exclusivamente em modelagem, seria uma relação NxN entre pessoas (ou seja, há uma tabela que representa isso, no caso, TabelaAmigos). Porém, essa tabela torna-se muito crítica e com muita responsabilidade em si mesma.

Eu separaria as associações de amizade e as amizades propriamente ditas. E talvez, as relações de amizade não-aceitas.

Por exemplo, na solicitação de amizade, geralmente há a mensagem de “justificativa” do pedido. Uma vez validada a amizade (aceita ou não), essa justificativa perde o sentido e seria “um campo morto” na tabela.
Outra preocupação é o aumento do volume de dados que iria impor uma carga cada vez maior da base para ler e atualizar a tabela de amigos, tornando lento o acesso aos pedidos de amizade.
Aí pode vir a pergunta, mas então, pedidos de amizade não aceitos ou amizades bloqueadas ficariam em outra base? Pode ser que sim, pode ser que não. Tudo depende da criticidade de cada uma.

E é claro, isso aumenta a complexidade do sistema com controles não-relacionais realizados por regras específicas e mantidas pela codificação (Exemplo: se há “pedido de amizade”, não há “amizade”).

Perfeito Welinton… era nessa análise que nosso amigo deveria ter chegado… Como é um trabalho de facul só pra nota, agora pode simplificar, mas Tiago, perceba a análise que o Welinton colocou aqui, tudo isso deve ser levado em conta, principalmente quando lidamos com modelo Relacional…

Porém um N x N resolve seu problema por agora. Você não pode ter idAmigo na tabela de Pessoa, pois a pessoa só teria 1 único amigo ??? Se fossem vários ??? Você iria inserir uma chave de id para cada novo amigo ???

Abs [] e sucesso no Projeto.

Uma PESSOA(Usuário) possui N RELACIONAMENTOs, uma relacionamento é formado por duas pessoas, cujo a ordem
das pessoas tem influência nos titulos do relacionamento. Acredito que a melhor abordagem é
criar uma Entidade para representar uma PESSOA e outra para representar o próprio RELACIONAMENTO.

Como a relação é de uma PESSOA pra muitos RELACIONAMENTOs, vc não pode criar um campo em PESSOA para reprensentar todos os RELACIONAMENTOs,
o certo é extrair todos para uma entidade afim de evitar as redundancias e normalizar, o RELACIONAMENTO tem seu próprio comportamento pois o status é
é alterado nele e não nas duas PESSOAs.

Você pode criar na entidade RELACIONAMENTO um campo para representar o status da aprovação (“APROVADO”, “PENDENTE”, “NEGADO”) do relacionamento e outro campo para o classificar
algo como “É amigo”, “É casado” ou “É filho”.

Como vc ainda não sabe se uma tabela associativa será um Bottleneck na sua aplicação o certo é modelar de uma forma mais coerente,
se no futuro após-implementado vc identificar um gargalo nesse ponto aplique técnicas de denormalização.

Se houver uma carga grande na tabela você ainda pode optar por criar rotinas de expurgos, removendo os registros com status cancelado após algum periodo
de validade do registro.

As informações de dominio também pode ser extraidas para tabelas.

Uma observação
Os relacionamentos são recursivos, eles sempre voltam para a mesma entidade Pessoa, não dá pra usar um auto-relacionamento ou tabela recursiva nesse caso, como é um caso n pra n acho que a saida é só pela associação.

O cara só quer um negócio simples:

1. João faz uma requisição de amizade para Maria

• requestorId = id do Joao
• targetId = id da Maria
• Criar registro na tabela REQUISICAO (requestorId, targetId)

2. Listar as requisicões enviadas para a Maria na página dela

• Buscar todos os registros na tabela REQUISICAO quando o targetId for igual ao id da Maria
• Para cada registro montar uma mensagem do tipo (Joao quer ser seu amigo - Aceitar ou não)

3. Maria recusa

• Exclui o registro da tabela REQUISICAO.

4. Maria aceita

• Cria registro na tabela AMIZADE (idJoao, idMaria)
• Exclui o registro da tabela REQUISICAO.

Primeira versão, simplicidade, sem complicar, sem burocracia, sem documentações toscas. Entregável. KISS.
Depois aprimora com validações e flores.

Também pode ser como o leandronsp falou, embora eu seja contra eliminar registos de um sistema, principalmente quando este é online.

das duas uma, ou eu alteraria somente a tabela REQUISIÇÃO: colocaria lá um campo estado com o valor de “recusado” e a respectiva data … ou criava uma tabela à parte, apenas para efeitos de histórico e consulta, com o requestorId, targetId , estado, data…

Forreta:

Também pode ser como o leandronsp falou, embora eu seja contra eliminar registos de um sistema, principalmente quando este é online.

das duas uma, ou eu alteraria somente a tabela REQUISIÇÃO: colocaria lá um campo estado com o valor de “recusado” e a respectiva data … ou criava uma tabela à parte, apenas para efeitos de histórico e consulta, com o requestorId, targetId , estado, data…

wellington.nogueira:

leandronsp:

O cara só quer um negócio simples:

…

Primeira versão, simplicidade, sem complicar, sem burocracia, sem documentações toscas. Entregável. KISS.
Depois aprimora com validações e flores.

Não discordo de você, mas é interessante (as vezes até necessário) antecipar possíveis problemas e DECIDIR se precisa deles imediatamente ou posteriormente.

• validação (depende do negócio) => quando um usuário x rejeitou o pedido de y, as requisições futuras de x para y não devem ser enviadas, mas para x não precisa dizer que ele foi rejeitado.
• estratégia de cache
• listar com paginação
• enfim…

Mas ainda acho que mesmo levantando esses possíveis problemas dá pra deixar eles somente no radar e desenvolver o básico. Fica mais fácil inclusive para escalar e pensar em outros possíveis problemas quando a coisa já está funcionando.

Digo isso pq já participei de projetos em que tive a oportunidade de desenvolver de uma vez só (levantando todos os requisitos) e outras desenvolvendo aos poucos, fazendo o negocio funcionar de fato. E nesta última opção a manutenção ficou muito mais fácil, mais escalar, código mais limpo e o cliente final mais satisfeito.

Pensando exclusivamente em modelagem, seria uma relação NxN entre pessoas (ou seja, há uma tabela que representa isso, no caso, TabelaAmigos). Porém, essa tabela torna-se muito crítica e com muita responsabilidade em si mesma.

Eu separaria as associações de amizade e as amizades propriamente ditas. E talvez, as relações de amizade não-aceitas.

Por exemplo, na solicitação de amizade, geralmente há a mensagem de “justificativa” do pedido. Uma vez validada a amizade (aceita ou não), essa justificativa perde o sentido e seria “um campo morto” na tabela.
Outra preocupação é o aumento do volume de dados que iria impor uma carga cada vez maior da base para ler e atualizar a tabela de amigos, tornando lento o acesso aos pedidos de amizade.
Aí pode vir a pergunta, mas então, pedidos de amizade não aceitos ou amizades bloqueadas ficariam em outra base? Pode ser que sim, pode ser que não. Tudo depende da criticidade de cada uma.

E é claro, isso aumenta a complexidade do sistema com controles não-relacionais realizados por regras específicas e mantidas pela codificação (Exemplo: se há “pedido de amizade”, não há “amizade”).

leandronsp:

O cara só quer um negócio simples:

…

Primeira versão, simplicidade, sem complicar, sem burocracia, sem documentações toscas. Entregável. KISS.
Depois aprimora com validações e flores.