Re: Vectores o matrices ... (perdón por lo extenso)

[Jonathan Sepúlveda B.]

y te falto explicar el outer join, cross join, left join y el left outer
join, y hay te creo.

salu2

todo caso en la pagina que haces referencia sale como join la simple
consulta que puse.

ahora toda la explicacion que te mandaste, ¿¿¿te sirve con un 386 con 16 mb
de ram???.


2006/11/9, Rodrigo Fuentealba <darkprox en gmail.com>:
>
> 2006/11/9, Alberto Rivera <rivera.alberto en gmail.com>:
> > Rodrigo Fuentealba escribió:
> > > Estimado:
> > >
> > > Antes que todo, usa ADOdb (adodb.sourceforge.net), así podrás evitarte
> > > mucho escándalo con el desorden.
> > >
> > Ok gracias, no lo conocia y al parecer está bastante más sencillo de
> > utilizar que el crudo php con mysql, ahora conoces alguna restricción de
> > plataforma o algo, ideal .. gracias ah :)
> >
>
> Restricción de plataforma? Sí, no he podido correrlo en mi tetris...
> <-! De hecho puedes trabajar hasta en Access con IIS y PHP, por lo que
> restricciones difícilmente hay. Puedes usar múltiples drivers.
>
> Ahora, un error:
>
> Cito:
>
> "a que se refiere con join, tienes tabla 1 con el rut del alumno y en
> la segunda tabla tambien tienes el rut del alumno creo yo, entonces
> tienes que hacer una consulta mas menos asi. select <campos> from
> tabla1,tabla2 where tabla1.rut = tabla2.rut"
>
> Eso no es usar joins, eso es hacer una consulta común y silvestre a
> dos tablas de la base de datos, y normalmente lo haces con alias.
>
> Un join es algo así: http://dev.mysql.com/doc/refman/5.0/en/join.html
> , y me gustaría mostrar el efecto:
>
> select hola from tabla 1 left join tabla2 on tabla1.datos = tabla2.datos;
>
> Mostremos el efecto con 100 tablas para tabla1 y tabla2:
>
> Con join:
>
> 100 datos de tabla 1 -> 100 operaciones de comparación y copia -> 100
> registros en memoria.
>
> 100 datos de tabla 2 -> 100 operaciones de comparación y copia -> 100
> registros más en memoria.
>
> Ahora, para descartar los datos, 100 contra 100: 10000 operaciones de
> comparación, + los registros resultantes en memoria.
>
> Una query normal:
>
> 100 datos de tabla 1 -> 100 operaciones de comparación y copia -> N
> (<=100) registros en memoria.
>
> 100 datos de tabla 2 -> 100 operaciones de comparación y copia -> N
> (<=100) registros más en memoria.
>
> La diferencia hasta aquí es que ya no tenemos 100 registros en
> memoria, sino los registros que cumplan la condición específica que le
> estamos dando. Luego, por alguna operación de cuenta, comparamos la
> tabla mayor con la tabla menor. Tenemos entonces, que la tabla mayor
> tiene (luego del filtrado) tenga 40 registros en memoria, y la menor,
> unas 20... El resultante de las operaciones de copia y comparación es
> 40 x 20 = 800.
>
> 800 contra 10000, es harta la diferencia de carga, y es harta la
> diferencia, dependiendo de qué tipo de filtrado se haga. En el peor de
> los casos retornaremos 10000 registros, si es que no existe relación
> entre ellos, que es lo mismo que JOINear ambas tablas
> indiscriminadamente, en el cual en el 100% de los casos tendrás ese
> rendimiento.
>
> En mi tiempo trabajando con bases de datos, he visto malas formas de
> trabajar, pésimas formas de trabajar y el uso indiscriminado de joins,
> debido a que utilizas mucha memoria y los mismos algoritmos que usas
> sobre datos comunes y corrientes bien indexados... pero sobre
> cantidades de código más grande. Consideren siempre antes de
> planificar una consulta compleja el cómo van a consumir menor cantidad
> de memoria.
>
> ¿Para qué sirve un join? si no tienes un buen método de optimización
> de consultas, solamente para llenar la memoria de datos.
>
> Ahora, ¿tablescanning? (recorrer N registros por query, siendo que no
> todos los vas a usar) Se evita con índices, gracias y buenas noches!
>
> --
> Rodrigo Fuentealba Cartes
> Desarrollador de Sistemas Web
> Registered User 387639 - http://counter.li.org
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://listas.inf.utfsm.cl/pipermail/php/attachments/20061109/1ec9d095/attachment.html