Re: Consulta compleja

Gracias por las respuestas,

En primer lugar, comentaros que he conseguido obtener el producto a través
del producto_id.

SELECT *tipo_producto* FROM *tabla_productos_por_cliente* WHERE *producto_id
*~('^'||*tipo_producto*::TEXT) ORDER BY LENGTH(*tipo_producto*) DESC LIMIT
1;

Con esta consulta me aseguro coger el tipo_producto que coincida con más
"dígitos" de producto_id.

Por otro lado, para conseguir los productos_id de tabla_tx a partir del
cliente pepito:

SELECT *tx*.*producto_id* FROM *tabla_tx* *tx* WHERE (SELECT *module_id*from
*s_route* WHERE *tx*.*producto_id*~('^'||*tipo_producto*::text) ORDER BY *
tipo_producto* DESC LIMIT 1)='pepito' ;

Con esta consulta recorro la tabla_tx, para cada producto_id obtengo el
tipo_producto i devuelvo aquellos productos_id que correspondan con el
cliente 'pepito'.

En fin, una compleja consulta causada por un mal diseño de la base de
datos. Por suerte, la tabla_tx almacena la fecha, donde esta consulta puede
limitarse a un corto período(1 mes).

En base a las respuesta, y ya que no soy dueño y señor del sistema,
propondré construir una nueva tabla donde se divida la información, para
que ayude a realizar nuevas consultas mas sencillas y no haya conflicto
entre los datos.

Alternativamente, la mejor solución seria reestructurar la base de datos,
pero creo que será una tarea imposible. (jejej)

Muchas gracias,

2013/1/18 Carlos Edward Grajales Marmolejo <cgrajales(at)colombiasoftware(dot)net>

> No se cual seria el motivo de tener informacion en este estilo, no es nada
> recomendable.
>
> Lo unico que se me ocurre es o bien crear un tabla aparte donde se divida
> la informacion y hacer la consulta por esa tabla o crear un nuevo campo en
> TX donde se extraiga la informacion que se requiere para poder generar la
> consulta.
> Dichos campos pueden ser alimentados por triggers.
>
>
>
> El 17 de enero de 2013 18:57, Jaime Casanova <jaime(at)2ndquadrant(dot)com>escribió:
>
>> 2013/1/17 Jose Luis Balle <joseluisballe(at)gmail(dot)com>
>> >
>> > Tienes problemas con el diseño de tus tablas.
>>
>> de acuerdo, el diseño que presenta Ruben no es bueno y puede que pueda
>> llegar a solucionar el problema de lentitud por ahora pero a menos que
>> arregle las consultas seguiran degradando en performance
>>
>> > Para tener dos tipos de valores en una misma columna tendrían que estar
>> separados por un token (#,.-=+ etc) o ser de longitud fija.
>>
>> no. eso no se hace nunca. hay mas de una razon para no almacenar
>> numeros como texto. ademas de que tendra problemas con los FK (por no
>> poder chequearlos como ahora), es mas ineficiente, ocupas mas espacio,
>> etc.
>>
>> porque esta puesto asi en lugar de en dos campos separados? o al menos
>> en un tipo de dato con dos campos separados.
>>
>> --
>> Jaime Casanova www.2ndQuadrant.com
>> Professional PostgreSQL: Soporte 24x7 y capacitación
>> Phone: +593 4 5107566 Cell: +593 987171157
>>
>> -
>> Enviado a la lista de correo pgsql-es-ayuda (
>> pgsql-es-ayuda(at)postgresql(dot)org)
>> Para cambiar tu suscripción:
>> http://www.postgresql.org/mailpref/pgsql-es-ayuda
>>
>
>
>
> --
> ------------------------------------------------------------------
>
>
>
> Cordialmente,
>
> *Carlos Edward Grajales*
> Colombia Software Ltda.
> Calle 18 N No. 3N-24 Ofc.902
> Cali - Colombia
> www.colombiasoftware.net
> Cel. 313 765 0594
> Tel: (2) 489 79 40

--
*Ruben Fitó *
Software Engineer
[image: Ubiquat Technologies, SL] r(dot)fito(at)ubiquat(dot)com<j(dot)catarineu(at)ubiquat(dot)com>

www.ubiquat.com
Tota la informació continguda en aquest document i arxius adjunts és
CONFIDENCIAL protegida per llei de secret comercial. Si l'ha rebut per
error, si us plau elimini'l i posi's en contacte amb l'emissor.

All information contained in this document and any attachments are
CONFIDENTIAL and protected under trade secret laws. If you receive this
message by mistake, please delete it and notify it immediately to the
sender.