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

[Rodrigo Fuentealba]

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