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
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 |