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

[Alberto Rivera]

Rodrigo Fuentealba escribió:
> 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.
no no no nada con iis o access uhhhh :)
>
>
> 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!
>