Re: Rv: Re: hacer que "" sea un NULL

--- Nahum Castro <pedro1_72(at)yahoo(dot)com> escribió:

> Fecha: Wed, 6 Jun 2007 14:55:02 -0500 (CDT)
> De: Nahum Castro <pedro1_72(at)yahoo(dot)com>
> Asunto: Re: [pgsql-es-ayuda] hacer que "" sea un
> NULL
> A: Agustin Casiva <casivaagustin(at)gmail(dot)com>
>
>
> --- Agustin Casiva <casivaagustin(at)gmail(dot)com>
> escribió:
>
> > Acabo de realizar una prueba con WITH NULL AS y me
> > lo cargo bien.
> >
> > copy test from '/var/lib/postgresql/load.txt' WITH
> > NULL AS '""';
> >
>
> estos son los errores que me manda:
>
> ajuste=# \copy trhog11 from
> '/home/nahum/ii_conteo/trhog11.csv' null as '""' csv
> quote '"'
> ERROR: el carácter de «quote» de CSV no debe
> aparecer
> en la especificación NULL
> \copy: ERROR: el carácter de «quote» de CSV no debe
> aparecer en la especificación NULL
> ajuste=# \copy trhog11 from
> '/home/nahum/ii_conteo/trhog11.csv' null as '""' csv
> ERROR: el carácter de «quote» de CSV no debe
> aparecer
> en la especificación NULL
> \copy: ERROR: el carácter de «quote» de CSV no debe
> aparecer en la especificación NULL
> ajuste=# \copy trhog11 from
> '/home/nahum/ii_conteo/trhog11.csv' null as '""'
> ERROR: el valor es demasiado largo para el tipo
> character varying(2)
> CONTEXTO: COPY trhog11, línea 1, columna ent:
> «"11","001","0288","003A","800","0001","1","5","11"»
>
> Saludos y gracias.
>
>
> --
> Nahum Castro
> Leon, Guanajuato, Mexico
> http://www.leon-linux.com
> e-mail: pedro1_72 [en] yahoo [punto] com
>
>
>
>
>
>
___________________________________________________________
>
> Do You Yahoo!?
> La mejor conexión a Internet y <b >2GB</b> extra a
> tu correo por $100 al mes. http://net.yahoo.com.mx
>
>

--
Nahum Castro
Leon, Guanajuato, Mexico
http://www.leon-linux.com
e-mail: pedro1_72 [en] yahoo [punto] com

Llama gratis a cualquier PC del mundo.
Con una excelente calidad de sonido.
http://mx.messenger.yahoo.com/

Esta mal tu consulta.

Copia y pega esto

copy trhog11 from '/home/nahum/ii_conteo/trhog1.csv' WITH NULL AS '""'

On 6/6/07, Nahum Castro <pedro1_72(at)yahoo(dot)com> wrote:
>
>
> --- Nahum Castro <pedro1_72(at)yahoo(dot)com> escribió:
>
> > Fecha: Wed, 6 Jun 2007 14:55:02 -0500 (CDT)
> > De: Nahum Castro <pedro1_72(at)yahoo(dot)com>
> > Asunto: Re: [pgsql-es-ayuda] hacer que "" sea un
> > NULL
> > A: Agustin Casiva <casivaagustin(at)gmail(dot)com>
> >
> >
> > --- Agustin Casiva <casivaagustin(at)gmail(dot)com>
> > escribió:
> >
> > > Acabo de realizar una prueba con WITH NULL AS y me
> > > lo cargo bien.
> > >
> > > copy test from '/var/lib/postgresql/load.txt' WITH
> > > NULL AS '""';
> > >
> >
> > estos son los errores que me manda:
> >
> > ajuste=# \copy trhog11 from
> > '/home/nahum/ii_conteo/trhog11.csv' null as '""' csv
> > quote '"'
> > ERROR: el carácter de «quote» de CSV no debe
> > aparecer
> > en la especificación NULL
> > \copy: ERROR: el carácter de «quote» de CSV no debe
> > aparecer en la especificación NULL
> > ajuste=# \copy trhog11 from
> > '/home/nahum/ii_conteo/trhog11.csv' null as '""' csv
> > ERROR: el carácter de «quote» de CSV no debe
> > aparecer
> > en la especificación NULL
> > \copy: ERROR: el carácter de «quote» de CSV no debe
> > aparecer en la especificación NULL
> > ajuste=# \copy trhog11 from
> > '/home/nahum/ii_conteo/trhog11.csv' null as '""'
> > ERROR: el valor es demasiado largo para el tipo
> > character varying(2)
> > CONTEXTO: COPY trhog11, línea 1, columna ent:
> > «"11","001","0288","003A","800","0001","1","5","11"»
> >
> > Saludos y gracias.
> >
> >
> > --
> > Nahum Castro
> > Leon, Guanajuato, Mexico
> > http://www.leon-linux.com
> > e-mail: pedro1_72 [en] yahoo [punto] com
> >
> >
> >
> >
> >
> >
> ___________________________________________________________
> >
> > Do You Yahoo!?
> > La mejor conexión a Internet y <b >2GB</b> extra a
> > tu correo por $100 al mes. http://net.yahoo.com.mx
> >
> >
>
>
> --
> Nahum Castro
> Leon, Guanajuato, Mexico
> http://www.leon-linux.com
> e-mail: pedro1_72 [en] yahoo [punto] com
>
>
> Llama gratis a cualquier PC del mundo.
> Con una excelente calidad de sonido.
> http://mx.messenger.yahoo.com/
>
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 8: explain analyze es tu amigo
>

--
Agustin Casiva

casivaagustin(at)gmail(dot)com

http://www.osis.com.ar
http://www.casivaagustin.com.ar

--- Agustin Casiva <casivaagustin(at)gmail(dot)com> escribió:

> Esta mal tu consulta.
>
> Copia y pega esto
>
> copy trhog11 from '/home/nahum/ii_conteo/trhog1.csv'
> WITH NULL AS '""'
>

ajuste=# copy trhog11 from
'/home/postgres/ii_conteo/trhog11.csv' WITH NULL AS
'""';
ERROR: el valor es demasiado largo para el tipo
character varying(2)
CONTEXTO: COPY trhog11, línea 1, columna ent:
«"11","001","0288","003A","800","0001","1","5","11"»

la columna ent es la primera, me parece que quiere
almacenar "11" (4 caracteres) no 11 (2 caracteres)

ajuste=# \d trhog11
Tabla «public.trhog11»
Columna | Tipo | Modificadores
----------+----------------------+---------------
ent | character varying(2) |
mun | character varying(3) |
loc | character varying(4) |
ageb | character varying(4) |
mza | character varying(3) |
cons_viv | character varying(4) |
cons_hog | integer |
toperhog | integer |
ticlahog | integer |

Solo cambie el el archivo al usuario postgres que es
el único que puede ejecutar copy.

Saludos y gracias.

--
Nahum Castro
Leon, Guanajuato, Mexico
http://www.leon-linux.com
e-mail: pedro1_72 [en] yahoo [punto] com

______________________________________________
¡Asómbrate! Conoce el Beta de Correo Yahoo! que incluye muchas herramientas que harán tu vida más sencilla.
http://correo.yahoo.com.mx/

On 6/6/07, Nahum Castro <pedro1_72(at)yahoo(dot)com> wrote:
>
>
> --- Agustin Casiva <casivaagustin(at)gmail(dot)com> escribió:
>
> > Esta mal tu consulta.
> >
> > Copia y pega esto
> >
> > copy trhog11 from '/home/nahum/ii_conteo/trhog1.csv'
> > WITH NULL AS '""'
> >
>
> ajuste=# copy trhog11 from
> '/home/postgres/ii_conteo/trhog11.csv' WITH NULL AS
> '""';
> ERROR: el valor es demasiado largo para el tipo
> character varying(2)
> CONTEXTO: COPY trhog11, línea 1, columna ent:
> «"11","001","0288","003A","800","0001","1","5","11"»
>
> la columna ent es la primera, me parece que quiere
> almacenar "11" (4 caracteres) no 11 (2 caracteres)
>
> ajuste=# \d trhog11
> Tabla «public.trhog11»
> Columna | Tipo | Modificadores
> ----------+----------------------+---------------
> ent | character varying(2) |
> mun | character varying(3) |
> loc | character varying(4) |
> ageb | character varying(4) |
> mza | character varying(3) |
> cons_viv | character varying(4) |
> cons_hog | integer |
> toperhog | integer |
> ticlahog | integer |
>
>
> Solo cambie el el archivo al usuario postgres que es
> el único que puede ejecutar copy.
>
> Saludos y gracias.
>

Bueno, pasamos el error de los enteros :-)

Te recomiendo que elimines todas las comillas, deja los datos como están.
Estas en lo cierto, quiere tomar "11" en vez de 11.

Elimina todas las comillas dobles del archivo y contá como fue.

Saludos

--
Agustin Casiva

casivaagustin(at)gmail(dot)com

http://www.osis.com.ar
http://www.casivaagustin.com.ar

Agustin Casiva escribió:

> Bueno, pasamos el error de los enteros :-)
>
> Te recomiendo que elimines todas las comillas, deja los datos como están.
> Estas en lo cierto, quiere tomar "11" en vez de 11.
>
> Elimina todas las comillas dobles del archivo y contá como fue.

Bueno, el problema aca seria que si un campo contiene una comilla doble
(aparte de las que delimitan la cadena), el valor quedara diferente :-(
A mi me parece que el archivo no es realmente valido segun la
especificacion que se ha dado.

A mi me parece que lo que el amigo deberia hacer es ingresar esas
cadenas como cadenas vacias en una tabla de pasada, y luego llevar los
datos desde esa tabla a otra que contenga la especificacion pedida.

(Otra solucion seria, como tu dices, quitar las comillas, pero no es tan
facil).

--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
La web junta la gente porque no importa que clase de mutante sexual seas,
tienes millones de posibles parejas. Pon "buscar gente que tengan sexo con
ciervos incendiándose", y el computador dirá "especifique el tipo de ciervo"
(Jason Alexander)

On 6/6/07, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
>
> Agustin Casiva escribió:
>
> > Bueno, pasamos el error de los enteros :-)
> >
> > Te recomiendo que elimines todas las comillas, deja los datos como
> están.
> > Estas en lo cierto, quiere tomar "11" en vez de 11.
> >
> > Elimina todas las comillas dobles del archivo y contá como fue.
>
> Bueno, el problema aca seria que si un campo contiene una comilla doble
> (aparte de las que delimitan la cadena), el valor quedara diferente :-(
> A mi me parece que el archivo no es realmente valido segun la
> especificacion que se ha dado.
>
A mi me parece que lo que el amigo deberia hacer es ingresar esas
> cadenas como cadenas vacias en una tabla de pasada, y luego llevar los
> datos desde esa tabla a otra que contenga la especificacion pedida.
>
> (Otra solucion seria, como tu dices, quitar las comillas, pero no es tan
> facil).

Ups!, es cierto, no tuve en cuenta lo que decis , X-).

Pero en caso de que dentro de los datos no existan comillas dobles podrían
eliminarse las mismas sin problemas.

Saludos
--
Agustin Casiva

casivaagustin(at)gmail(dot)com

http://www.osis.com.ar
http://www.casivaagustin.com.ar

--- Agustin Casiva <casivaagustin(at)gmail(dot)com> escribió:

> On 6/6/07, Alvaro Herrera
> <alvherre(at)commandprompt(dot)com> wrote:
> >
> > Agustin Casiva escribió:
> >
> > > Bueno, pasamos el error de los enteros :-)
> > >
> > > Te recomiendo que elimines todas las comillas,
> deja los datos como
> > están.
> > > Estas en lo cierto, quiere tomar "11" en vez de
> 11.
> > >
> > > Elimina todas las comillas dobles del archivo y
> contá como fue.
> >
Se eliminan las comillas con:

$cat trviv11.csv | sed s/\"//g > trviv11_c.csv

El archivo csv lo obtuve viendo los post anteriores,
en alguno de ellos comentan de una herramienta dbf2csv
que esta en perl, esta es la que genera los archivos
csv con comillas.

Una vez generado el archivo las comillas dobles se
eliminan con el comando de arriba, este archivo ya se
puede utilizar con el copy sin ningún problema.

copy trviv11 from
'/home/postgres/ii_conteo/trviv11_c.csv'
WITH CSV;

Saludos y gracias a tod(at)s(dot)

--
Nahum Castro
Leon, Guanajuato, Mexico
http://www.leon-linux.com
e-mail: pedro1_72 [en] yahoo [punto] com

______________________________________________
¡Asómbrate! Conoce el Beta de Correo Yahoo! que incluye muchas herramientas que harán tu vida más sencilla.
http://correo.yahoo.com.mx/

Buenas,

Que opción es mejor desde el punto de vista de rendimiento:

T_1 JOIN T_2
T_2 JOIN T_3

o

T_1 join T_2
T_1 join T_3

En el caso, por supuesto, en que sea indiferente que T_3 tenga clave a T_2 ó
T_1.

Gracias, un saludo

El 29/06/07, jlcambero <jlcambero(at)emergya(dot)es> escribió:
> Buenas,
>
> Que opción es mejor desde el punto de vista de rendimiento:
>
> T_1 JOIN T_2
> T_2 JOIN T_3
>
> o
>
> T_1 join T_2
> T_1 join T_3
>
> En el caso, por supuesto, en que sea indiferente que T_3 tenga clave a T_2 ó
> T_1.
>

Ninguna. Básicamente, porque las 2 opciones son INCORRECTAS.
Deberías revisar la sintaxis del join:
T_1 JOIN T_2 on condiciones.... JOIN T_3 on condiciones...
Podrás usar paréntesis para alterar el orden normal, y la verdad es
que no sé si influirá en el rendimiento. Yo dejaría al optimizador que
se buscase la vida :)

El Viernes, 29 de Junio de 2007 13:11, Miguel Rodríguez Penabad escribió:
> El 29/06/07, jlcambero <jlcambero(at)emergya(dot)es> escribió:
> > Buenas,
> >
> > Que opción es mejor desde el punto de vista de rendimiento:
> >
> > T_1 JOIN T_2
> > T_2 JOIN T_3
> >
> > o
> >
> > T_1 join T_2
> > T_1 join T_3
> >
> > En el caso, por supuesto, en que sea indiferente que T_3 tenga clave a
> > T_2 ó T_1.
>
> Ninguna. Básicamente, porque las 2 opciones son INCORRECTAS.
> Deberías revisar la sintaxis del join:
> T_1 JOIN T_2 on condiciones.... JOIN T_3 on condiciones...
> Podrás usar paréntesis para alterar el orden normal, y la verdad es
> que no sé si influirá en el rendimiento. Yo dejaría al optimizador que
> se buscase la vida :)
> --
> ---------------------------(fin del mensaje)---------------------------
> TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

Por si no te habias dado cuenta es una especie de "pseudocodigo".
Y depende de como relacione las tablas en el modelo de datos, asi actuara el
optimizador, vamos digo yo.

> Por si no te habias dado cuenta es una especie de "pseudocodigo".

Ya, pero pseudocódigo erróneo.

Si quieres sumar el 1, el 2 y el 3 puedes hacer (1+2)+3 o 1+(2+3).
No tiene sentido que digas 1+2, 1+3 o 1+2, 2+3
A eso me refería.

Si haces T1 join T2 join T3
hará X <-- (T1 join T2) , y luego X join T3. Nunca hará T1 join T3 ni
T2 join T3
o
X <-- (T2 join T3), y luego T1 join X. De nuevo, nunca T1 join T3 o T1 join T2

Yo lo dejaría sin paréntesis, y el optimizador decide el orden,
basándose en el número
de filas de cada relación, las filas esperadas para cada join, ...

El Viernes, 29 de Junio de 2007 13:45, Miguel Rodríguez Penabad escribió:
> > Por si no te habias dado cuenta es una especie de "pseudocodigo".
>
> Ya, pero pseudocódigo erróneo.
>
> Si quieres sumar el 1, el 2 y el 3 puedes hacer (1+2)+3 o 1+(2+3).
> No tiene sentido que digas 1+2, 1+3 o 1+2, 2+3
> A eso me refería.
>
> Si haces T1 join T2 join T3
> hará X <-- (T1 join T2) , y luego X join T3. Nunca hará T1 join T3 ni
> T2 join T3
> o
> X <-- (T2 join T3), y luego T1 join X. De nuevo, nunca T1 join T3 o T1
> join T2
>
> Yo lo dejaría sin paréntesis, y el optimizador decide el orden,
> basándose en el número
> de filas de cada relación, las filas esperadas para cada join, ...
> --

To dije:
> En el caso, por supuesto, en que sea indiferente que T_3 tenga clave a T_2 ó
> T_1.

Puede que no me haya explicado muy bien. a ver ahora:
Yo tengo una tabla T_3 en la que me es indiferente (semanticamente) tener una
clave a T_2 o tener una clave a T_1. (solo tendra una clave ajena)

ahora en temas de rendimiento que es mejor hacer join de una tabla con 2
tablas:
T_1 join T_2
T_1 join T_3

o hacer join de una tabla con otra tabla que a su vez hace join con una
tercera:

T_1 join T_2
T_2 join T_3

Espero haberme explicado mejor esta vez.

Un saludo

> Puede que no me haya explicado muy bien. a ver ahora:

Yo sigo viéndolo erróneo. Quizás soy yo o el fin de semana que se acerca, pero
¿podrías poner un ejemplo REAL de la consulta?

> Yo tengo una tabla T_3 en la que me es indiferente (semanticamente) tener una
> clave a T_2 o tener una clave a T_1. (solo tendra una clave ajena)

Bien. Supongamos tres tablas:
T_1(clave, campo1)
T_2(clave, campo2)
T_3(clave, campo3)
¿Hasta aquí correcto?

> ahora en temas de rendimiento que es mejor hacer join de una tabla con 2
> tablas:
> T_1 join T_2
> T_1 join T_3

Esto son DOS resultados:
T_1 join T_2 tendrá un esquema del tipo JOIN_1(clave, campo1, campo2)
T_1 join T_3 tendrá un esquema del tipo JOIN_2(clave, campo1, campo3)
¿Que quieres hacer con estos dos resultados? ¿un join? otra cosa, como
unión o intersección no es posible al tener esquemas distintos...
y hacer los dos anteriores y luego JOIN_1 join JOIN_2 no va a ser eficiente.

> o hacer join de una tabla con otra tabla que a su vez hace join con una
> tercera:
>
> T_1 join T_2
> T_2 join T_3

También son 2 resultados.

Por favor, pon la consulta real que quieres y te prodremos ayudar mejor.
O, quizás hay alguien por ahí que entiende algo que yo no...

Saludos
Miguel

jlcambero escribió:

> Puede que no me haya explicado muy bien. a ver ahora:
> Yo tengo una tabla T_3 en la que me es indiferente (semanticamente) tener una
> clave a T_2 o tener una clave a T_1. (solo tendra una clave ajena)
>
> ahora en temas de rendimiento que es mejor hacer join de una tabla con 2
> tablas:
> T_1 join T_2
> T_1 join T_3

Quizas quieres decir esto: que es mejor,

(T1 join T2) join (T2 join T3)
versus
(T1 join T2) join (T1 join T3)

La respuesta es: ninguna de las dos, es mas inteligente hacer

(T1 join T2) join T3

y en este caso es indiferente si T3 tiene una llave a T1 o a T2; el
optimizador reordenará el join de la manera más eficiente.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

> (T1 join T2) join (T2 join T3)
> versus
> (T1 join T2) join (T1 join T3)
>
> La respuesta es: ninguna de las dos, es mas
> inteligente hacer
>
> (T1 join T2) join T3
>
> y en este caso es indiferente si T3 tiene una llave
> a T1 o a T2; el
> optimizador reordenará el join de la manera más
> eficiente.
Mira que bueno, ahi tenes otro Tips, analiza bien tus
Join, puedes alcanzar mejor Rendimiento.

>
> --
> Alvaro Herrera
> http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
> --
> ---------------------------(fin del
> mensaje)---------------------------
> TIP 7: no olvides aumentar la configuración del
> "free space map"
>

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.espanol.yahoo.com/

Gabriel Hermes Colina Zambra escribió:
>
> > (T1 join T2) join (T2 join T3)
> > versus
> > (T1 join T2) join (T1 join T3)
> >
> > La respuesta es: ninguna de las dos, es mas
> > inteligente hacer
> >
> > (T1 join T2) join T3
> >
> > y en este caso es indiferente si T3 tiene una llave
> > a T1 o a T2; el
> > optimizador reordenará el join de la manera más
> > eficiente.
> Mira que bueno, ahi tenes otro Tips, analiza bien tus
> Join, puedes alcanzar mejor Rendimiento.

Es que en realidad el sistema deberia hacer eso automaticamente (y lo
hace, con buenos resultados en la mayoria de los casos)

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

On 6/29/07, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> jlcambero escribió:
>
> > Puede que no me haya explicado muy bien. a ver ahora:
> > Yo tengo una tabla T_3 en la que me es indiferente (semanticamente) tener una
> > clave a T_2 o tener una clave a T_1. (solo tendra una clave ajena)
> >
> > ahora en temas de rendimiento que es mejor hacer join de una tabla con 2
> > tablas:
> > T_1 join T_2
> > T_1 join T_3
>
> Quizas quieres decir esto: que es mejor,
>
> (T1 join T2) join (T2 join T3)
> versus
> (T1 join T2) join (T1 join T3)
>
> La respuesta es: ninguna de las dos, es mas inteligente hacer
>
> (T1 join T2) join T3
>
> y en este caso es indiferente si T3 tiene una llave a T1 o a T2; el
> optimizador reordenará el join de la manera más eficiente.
>

a menos que tengas join_collapse_limit = 1

--
Atentamente,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook

El Viernes, 29 de Junio de 2007 16:03, Alvaro Herrera escribió:
> jlcambero escribió:
> > Puede que no me haya explicado muy bien. a ver ahora:
> > Yo tengo una tabla T_3 en la que me es indiferente (semanticamente) tener
> > una clave a T_2 o tener una clave a T_1. (solo tendra una clave ajena)
> >
> > ahora en temas de rendimiento que es mejor hacer join de una tabla con 2
> > tablas:
> > T_1 join T_2
> > T_1 join T_3
>
> Quizas quieres decir esto: que es mejor,
>
> (T1 join T2) join (T2 join T3)
> versus
> (T1 join T2) join (T1 join T3)
>
> La respuesta es: ninguna de las dos, es mas inteligente hacer
>
> (T1 join T2) join T3
>
> y en este caso es indiferente si T3 tiene una llave a T1 o a T2; el
> optimizador reordenará el join de la manera más eficiente.

Gracias

El Viernes, 29 de Junio de 2007 15:54, Miguel Rodríguez Penabad escribió:
> > Puede que no me haya explicado muy bien. a ver ahora:
>
> Yo sigo viéndolo erróneo. Quizás soy yo o el fin de semana que se acerca,
> pero ¿podrías poner un ejemplo REAL de la consulta?
>
> > Yo tengo una tabla T_3 en la que me es indiferente (semanticamente) tener
> > una clave a T_2 o tener una clave a T_1. (solo tendra una clave ajena)
>
> Bien. Supongamos tres tablas:
> T_1(clave, campo1)
> T_2(clave, campo2)
> T_3(clave, campo3)
> ¿Hasta aquí correcto?
>
> > ahora en temas de rendimiento que es mejor hacer join de una tabla con 2
> > tablas:
> > T_1 join T_2
> > T_1 join T_3
>
> Esto son DOS resultados:
> T_1 join T_2 tendrá un esquema del tipo JOIN_1(clave, campo1, campo2)
> T_1 join T_3 tendrá un esquema del tipo JOIN_2(clave, campo1, campo3)
> ¿Que quieres hacer con estos dos resultados? ¿un join? otra cosa, como
> unión o intersección no es posible al tener esquemas distintos...
> y hacer los dos anteriores y luego JOIN_1 join JOIN_2 no va a ser eficiente

cierto, es erroneo.
Era yo o la llegada del fin de semana :-P

Gracias, un saludo