Re: [OT] - Estrategia de tablas (red social -muchos a muchos-).

From: Álvaro Hernández Tortosa <aht(at)Nosys(dot)es>
To: yapt(at)technovell(dot)com
Cc: pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: [OT] - Estrategia de tablas (red social -muchos a muchos-).
Date: 2011-05-09 15:12:36
Message-ID: 20110509151236.GK14460@nosys.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda


Hola, alguna sugerencia rápida IMHO:

Mon, May 09, 2011 at 10:10:25AM -0400, yapt(at)technovell(dot)com escribió:

>Los problemas que me encuentro:
>**** 1.- Debo mantener "manualmente" (con triggers, rules o como sea)
>dobles entradas.
>
>Es decir, si Pepe conoce a Juan, debo hacer:
>
>Tabla 2 (idUsuario / IdUsuarioConocido)
>* Pepe -> Juan
>* Juan -> Pepe (esta debo crearla yo vía triggers o similar).
>(también debo mantener los DELETES/UPDATES, etc..).

No lo hagas. Principio fundamental en bbdd: que no haya nunca
información duplicada (o inferible), porque precisamente cualquier error
en su mantenimiento puede dar lugar a información inconsistente.

Si Pepe -> Juan entonces es fácil deducir que Juan -> Pepe.
Rehaz tus consultas o vistas para tener esto en cuenta, pero nunca
dupliques info.

>
>
>**** 2.- Si P, conoce a J .... y J, conoce a K.... entonces P conoce a
>K
>¿ Donde parar con esta consulta ?

Esto lo define la lógica de negocio...

>¿ Como efectuarla de forma optima ?

Si conoces el número de niveles máximo y es fijo, entonces haz N
self joins, uno por cada nivel. Si no lo conoces pero puedes establecer
una condición de parada, usa WITH RECURSIVE con self joins. En ningún
caso, hagas subselects...

Espero haber podido ayudar. Saludos,

Álvaro

--

Álvaro Hernández Tortosa

-----------
NOSYS
Networked Open SYStems

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Marcos Matamala 2011-05-09 15:33:58 Re: [OT] - Estrategia de tablas (red social -muchos a muchos-).
Previous Message Álvaro Hernández Tortosa 2011-05-09 14:48:33 Re: shared_buffers