From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | yapt <yapt(at)technovell(dot)com> |
Cc: | pgsql-es-ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: [OT] - Estrategia de tablas (red social -muchos a muchos-). |
Date: | 2011-05-09 16:13:51 |
Message-ID: | 1304957289-sup-8219@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Excerpts from yapt's message of lun may 09 10:10:25 -0400 2011:
> Es decir, Juan conoce a Pepe, Pepe conoce a Pedro, Andrés conoce a
> Pedro, etc.. etc.. Creo que sería una especie de relación
> muchos-a-muchos...
>
> En lo que estoy un poco perdido es en como representar esta relación en
> tablas de base de datos y su consistencia. PostgreSQL en este caso
> (aunque podría ser cualquier otra).
>
> Se admiten ideas teórico-prácticas de todo tipo.
Si Alicia dice conocer a Bernardo, ¿le da esto a Bernardo autorización
sobre datos de Alicia? Si es así entonces es mala idea marcar
automáticamente que Bernardo conoce a Alicia, porqe quizás Bernardo no
quiere compartir información con Alicia. Por lo tanto creo que
necesitas otra tabla para registrar "posibles conocidos", es decir la
relación B->A cuando A añade B; y preguntarle a B si realmente conoce a
A. Si dice que no, ¿qué hacer? Y en cualquier caso la respuesta de B
debe almacenarse.
Igual con la transitividad. Si Alicia conoce a Bernardo y Bernardo
conoce a Claudia, ¿conoce Alicia a Claudia? Quizás sí, quizás no;
entonces podrías "sugerir" a Alicia que es posible que conozca a Claudia
y actúa según lo que Alicia te responda.
Facebook y otros sitios sociales hacen esto, pero obviamente mucho más
elaborado.
--
Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
From | Date | Subject | |
---|---|---|---|
Next Message | Roberto Andrade Fonseca | 2011-05-09 16:38:59 | PostgreSQL 9.1 en Information Week |
Previous Message | Marcos Matamala | 2011-05-09 15:33:58 | Re: [OT] - Estrategia de tablas (red social -muchos a muchos-). |