Cálculos en php o mysql?

[hexapodo]

Hola,

que es mas aconsejable, hacer los cálculos en mysql directamente y recoger el resultado o hacer una consulta, recoger los resultados en un array de php y hacer los cálculos desde el php?
Lo que voy a calcular es la desviación estándar de una serie de números (unos 200 números o mas.)

gracias

[yacatl]

Pues es mejor hacerlo de una sola vez.

Saludos!

[nicolaspar]

Es mejor distribuir los trabajos según como esten distribuidos los recursos en el servidor. Esto que te digo es en grande proyectos, con grandes consultas permanentes, donde la minima cosa hace la diferencia.
Con esto estoy diciendo que en el caso de la db, lo unico que deberia hacer es servir los datos, no procesaros, de esa tarea es mejor se encargue el servidor (apache, iis, etc).

Si no es tu caso, es relativamente lo mismo.

[Cluster]

Iniciado por nicolaspar

Es mejor distribuir los trabajos según como esten distribuidos los recursos en el servidor. Esto que te digo es en grande proyectos, con grandes consultas permanentes, donde la minima cosa hace la diferencia.
Con esto estoy diciendo que en el caso de la db, lo unico que deberia hacer es servir los datos, no procesaros, de esa tarea es mejor se encargue el servidor (apache, iis, etc).

Si no es tu caso, es relativamente lo mismo.

Bueno .. en ese caso no comparto la opiniòn .. (me explico)

Fijate que el "Lenguaje Estructurado de Consultas" (SQL) disponde de multitud de funciones para operar (con Numeros, Strings, Condicionales (si, extructuras condicionales: IF() ..etc ) .. funciones store procedure (en los RDBMS que lo soporten) .. etc) ..

Bajo mi punto de vista y rendimiento .. que trabaje un dato internamente una BD es màs òptimo que extraer el dato y luego dejar que lo procese otro lenguaje (PHP en ese caso) .. Yo soy de la filosofìa de "todo lo que puedas hacer con SQL .. no lo hagas con otro lenguaje" .. He podido comprobar en algunos casos que haciendo la misma operaciòn PHP+SQL ha sido menos óptimo que con SQL (hablando de hacer algùn cálculo, trabajo con strings ...).

Deja a tu servidor HTTP que haga su trabajo: "servir pàginas" y a PHP al suyo "pre-procesar las pàginas" .. Los datos dejalos que lo trabje tu BD con su pròpio lenguaje SQL. Por el mimo hecho de un sistema distribuido donde tienes uno o varios servidores de "Base de datos" .. y tu servidor HTTP (con PHP en el como lenguaje del lado del servidor), no "colapsaras" al servidor HTTP por què està haciendo un cálculo (por parte de PHP) . si "colapsas" al servidor de Base de datos .. siempre puedes controlar mejor ese evento: tu página la serviras ..pero si no puedes conectarte a tu BD .. puedes mostrar tu mensaje de aviso en consecuencia.

Ademàs que te haces màs independiente del lenguaje de programaciòn usado .. siendo màs portable tu "modelo de datos" y Base de datos a otros lenguajes. Ejemplo tìpico .. tenemos ciertos datos que obtener de una Base de datos (con algunos cálculos tipo "sumatorios" .. "subtotales" .. por ejemplo) .. Esos datos por A o B motivo los tenemos que procesar con PHP y otro lenguaje que acceda directamente al igual que lo hace PHP a la BD (por ejemplo "Visual Basic") .. Si haces el trabajo una vez en SQL .. no tendras que "replicar" còdigo similar en los dos ambientes, simplificas las aplicaciones y ganas en productividad.

Un saludo,

[nicolaspar]

Bueno, como decia en mi post, distribuir los trabajos es lo mas optimo, por que en el caso, como vos mensionas, de querer obtener un dato y no poder por que las consultas estan saturando al servidor de db, haría que la pagina no se muestre, y que el sitio por completo deje de funcionar.
Estoy llevando esto al estremo en donde todas las pagina contienen sql, y donde las visitas son muchas y simultaneas...me ha pasado esto, y creeme, no se lo recomiendo a nadie.
En cuanto a lo que vos decis, si el query esta bien extructurado, y la db bien normalizada y diseñada, es muy valido para la generalidad, pero no quita que sea lo correcto y lo incorrecto.

Como consecuencia de esto, afirmo, por ejemplo, nunca usar cursores, que si bien en mysql no existen todavía definitivamente, en este si existen tablas temporales que tampoco recomiendo, variables y demas cosas en sql a no ser que sea sumamente necesario.


Yo antes usaba mucho esto, hasta que me tope con casos que me hicieron recapacitarme, y si bien hoy uso cosas como if, ifnull,concat, sum, count, abs, ln, log, cot, mod, radians, substring, etc, se donde las uso, y soy consiente de su costo.
Igual me falta toparme con muchas cosas, y Ojo que tal vez tenemos conseptos diferentes de "calculos en sql".
También hay algo de veradad en esto, y es que generalice a varios motores en esto, no solo a mysql, sabiendo que el thread apuntaba a mysql.

Saludos, espero no haber cansado con esto.

[Cluster]

Saludos, espero no haber cansado con esto.

De esto trata el mensaje .. cada uno aporta con su experiencia o referencias ..

Como bien comentas .. se ha intentado "generalizar" .. por ejemplo .. si bien Mysql no soporta Cursores y en MS SQL Server no sea "óptimo usarlos" .. tal vez en otro RDMBS sean más optimo su implementación .. o usen otras técnicas para implementarlo (si no me equivoco en Mysql LIMIT sería una "solución" al uso de cursores de MS SQL Server para algunas taréas de ese estilo ..).

Cada caso habría que estudiarlo en particular .. En "promedio" para los casos que habitualmente trabajo con Base de datos .. me ha dado buen resultado (uso principalmente Mysql) usar lo más posible SQL para resolver un problema .. de hecho cuando "tengo tiempo" suelo hacer la prueba PHP+SQL vs SQL sólo para ver si realmente vale la pena .. Me facilita mucho la taréa tomar mi "GUI" para Mysql .. armar la sentencia SQL . .probarla y si resulta pasarla a mi script PHP que tan sólo "recorre el resultado" sin más procesos por médio para darle su salida en general.



Un saludo,

[nicolaspar]

Si, en general hago lo mismo, pero a modo de recomendacion siempre digo "depende", por que en si, siempre depende de hasta donde venga el viento, pero todo influye, hasta el tipo de db según sea el caso (myisam, innodb, heap, gimini, etc). Pero buee...ya nos vamos a determinados proyectos y nos salimos de la generalizacion, o tal vez no...ya no se:P

[cita]
Mysql no soporta Cursores y en MS SQL Server no sea "óptimo usarlos" .. tal vez en otro RDMBS sean más optimo su implementación .. o usen otras técnicas para implementarlo (si no me equivoco en Mysql LIMIT sería una "solución" al uso de cursores de MS SQL Server para algunas taréas de ese estilo ..).
[/cita]
Son cursores, donde sea, por mas veloz que su competencia, serán renegadamente cursores.
Por ejemplo, yo he hehco cosas que dentro de un sp tiene unos 8 cursores, y por lo menos 4 tablas tmp, y si bien eran necesarios y esto no responde en un segundo (serán 5 seg aprox), nunca ha tenido problemas, pero no se consulta mas de 10 veces simultaneamente...no se si me explico.
A lo que voy es que pueden ser optimos según el caso.

No se a que te referis con el limit, pero si es al paginado, al menos yo no uso cursores para su remplazo.

[Cluster]

No se a que te referis con el limit, pero si es al paginado, al menos yo no uso cursores para su remplazo.

Ok, .. no uso SQL Server .. alguna vez ví algo que solventaba ese problema de "paginado" con cursores .. (tal vez me equivoqué o estoy confundiendo términos).

Lo que si que es cierto que aquí en el foro de PHP se suele preguntar "como paginar con MS SQL server" .. sobre literatura al respecto vs Msyql hay mucho .. (no estaría de más una FAQ al respecto .. aunque eso ya es otro tema ..).


------------------------

Volviendo al tema inicial:

Lo que voy a calcular es la desviación estándar de una serie de números (unos 200 números o mas.)

Supongo que a estas alturas ya habrá resuelto el problema .... mas o menos óptimo .. estaría bueno que presentase resultados de ambas versiones o que lo intente resolver de ambas formas ..

Un saludo,

[hexapodo]

Muchas gracias por lo comentado, lo voy a tener en cuenta,

Mi aplicacion no es muy grande pero debe hacer algunos calculos recorriendo una tabla de 2500 campos y sacar media aritmetica, desviacion estandar y otros dato estadisticos.

gracias y chao