soporta - php mysql ejemplos

Hacer cálculos en MySQL vs PHP (5)

Contexto:

Tenemos una aplicación PHP / MySQL.
Algunas partes de los cálculos se realizan en SQL directamente. Por ejemplo: todos los usuarios creados en las últimas 24 horas serían devueltos a través de una consulta SQL (AHORA () - 1 día)

Existe un debate entre un desarrollador compañero y yo en el que tengo la opinión de que debemos:

A. Guarde todos los cálculos / código / lógica en PHP y trate a MySQL como un repositorio "tonto" de información

Su opinion:

B. Hacer una mezcla y combinar según lo que sea más fácil / más rápido. http://www.onextrapixel.com/2010/06/23/mysql-has-functions-part-5-php-vs-mysql-performance/

Estoy mirando el punto de vista de la mantenibilidad. Está buscando la velocidad (que, como señala el artículo, algunas operaciones son más rápidas en MySQL).

@ bob-the-destroyer @tekretic @OMG Ponies @mu es demasiado corto @Tudor Constantin @tandu @Harley

Acepto (y obviamente) las cláusulas WHERE eficientes en el nivel SQL. Sin embargo, ¿qué pasa con ejemplos como:

Cálculo de un período de 24 usando NOW () - 1 día en SQL para seleccionar todos los usuarios creados en las últimas 24 horas?
¿Devuelve el nombre y el apellido en mayúsculas de todos los usuarios?
Concatenando una cuerda?
(Pensamientos, amigos?)

Ejemplos claros que pertenecen al dominio SQL:

selecciones WHERE específicas
Declaraciones SQL anidadas
Ordenar / ordenar
Selección de elementos DISTINCT
Recuento de filas / artículos

El tiempo necesario para recuperar los datos en SQL lleva mucho tiempo, pero una vez que los cálculos se han completado, son más de lo mismo. No tomará mucho tiempo de ninguna manera después de que se obtengan los datos, pero hacerlo inteligentemente en el SQL puede dar mejores resultados para grandes conjuntos de datos.

Si está obteniendo datos de MYSQL y luego haciendo los cálculos en PHP sobre los datos obtenidos, entonces es mucho mejor buscar el resultado requerido y evitar el procesamiento de PHP, ya que aumentará más tiempo.

Algunos puntos básicos:

El formato de fecha en MYSQL es sólido, la mayoría de los formatos están disponibles en Mysql. Si tienes un formato de fecha muy específico, entonces puedes hacerlo PHP.
La manipulación de cadenas simplemente apesta en SQL, mejor hazlo en PHP. Si no necesita hacer una gran manipulación de cadenas, puede hacerlo en Mysql SELECTs.
Al seleccionar, cualquier cosa que reduzca el número de registros debe ser hecha por el SQL y no por PHP
Los datos de pedido siempre deben hacerse en Mysql
La agregación siempre debe hacerse en Mysql porque los motores de DB están específicamente diseñados para esto.
Las sub-consultas y uniones siempre deben estar en el lado de la base de datos. Reducirá tus lotes de código PHP. Cuando necesita obtener datos de 2 o más tablas a la vez, una vez más, SQL es mucho mejor que PHP
Quiere contar los registros, SQL es genial.

Jugaría a las fortalezas de cada sistema.

La lógica de agregación, unión y filtrado obviamente pertenece a la capa de datos. Es más rápido, no solo porque la mayoría de los motores de DB tienen más de 10 años de optimización para hacer justamente eso, sino que minimiza los datos intercambiados entre su base de datos y el servidor web.

Por otro lado, la mayoría de las plataformas de DB que he usado tienen una funcionalidad muy pobre para trabajar con valores individuales. A las cosas les gusta el formato de fecha y la manipulación de cadenas, solo aspiran el SQL, es mejor que lo hagan en PHP.

Básicamente, use cada sistema para lo que está diseñado para hacer.

En términos de mantenibilidad, siempre y cuando la división entre lo que sucede donde está claro, separar estos a tipos de lógica no debería causar muchos problemas y ciertamente no lo suficiente como para que salgan los beneficios. En mi opinión, la claridad y la mantenibilidad del código tienen que ver más con la coherencia que con poner toda la lógica en un solo lugar.

Re: ejemplos específicos ...

Sé que esto no es a lo que te refieres también, pero las fechas son casi un caso especial. Desea asegurarse de que todas las fechas generadas por el sistema se creen en el servidor web O en la base de datos. Hacer lo contrario causará algunos errores insidiosos si el servidor db y el servidor web alguna vez están configurados para diferentes zonas horarias (he visto esto suceder). Imagine, por ejemplo, que tiene una columna createdDate con un valor predeterminado de getDate() que se aplica al insertar por el DB . Si date("Ymd", time() - 3600) que insertar un registro, utilizando una fecha generada en PHP (por ejemplo, date("Ymd", time() - 3600) , seleccione los registros creados en la última hora, es posible que no obtenga lo que espera. En cuanto a qué capa Debería hacer esto en, preferiría el DB para, como en el ejemplo, le permite usar los valores por defecto de las columnas.
Para la mayoría de las aplicaciones, haría esto en PHP. Combinar nombre y apellido suena simple hasta que te das cuenta de que necesitas saludos, títulos e iniciales del medio también a veces. Además, es casi seguro que terminará en una situación en la que desee un nombre de usuario, un apellido Y un saludo de combinación + nombre + apellido. Concatenarlos en el lado de DB significa que terminas moviendo más datos, aunque en realidad es bastante menor.
Depende Como se mencionó anteriormente, si alguna vez desea usarlos por separado, es mejor que los saque por separado y concatene cuando sea necesario. Dicho esto, a menos que los conjuntos de datos con los que trabajes sean enormes, es probable que haya otros factores (como, como mencionas, mantenimiento) que tienen más peso.

Algunas reglas generales:

La generación de identificadores incrementales debería ocurrir en la base de datos.
Personalmente, me gusta mi valor predeterminado aplicado por el DB.
Al seleccionar, cualquier cosa que reduzca el número de registros debe ser hecha por el DB.
Por lo general, es bueno hacer cosas que reducen el tamaño del conjunto de datos DB-side (como en el ejemplo de cadenas de caracteres anterior).
Y como dices; orden, agregación, subconsultas, uniones, etc. siempre deben estar en el lado de la base de datos.
Además, no hemos hablado sobre ellos, pero los factores desencadenantes suelen ser malos / necesarios.

Hay algunas desventajas centrales que enfrenta aquí y el saldo realmente depende de su aplicación.

Algunas cosas deberían, definitivamente, siempre, hacerse en SQL. Excluyendo algunas excepciones (como las fechas) para muchas tareas SQL puede ser muy torpe y puede dejarte con la lógica en lugares fuera del camino. Al buscar en su base de código referencias para una columna específica (por ejemplo), es fácil pasar por alto las contenidas en una vista o procedimiento almacenado.

El rendimiento siempre es una consideración pero, dependiendo de su aplicación y el ejemplo específico, tal vez no sea uno grande. Sus preocupaciones sobre la mantenibilidad y probablemente muy válidas y algunos de los beneficios de rendimiento que he mencionado son muy leves, así que tenga cuidado con la optimización prematura.

Además, si otros sistemas están accediendo directamente a la base de datos (por ejemplo, para informes, o importaciones / exportaciones), se beneficiará al tener más lógica en la base de datos. Por ejemplo, si desea importar usuarios de otra fuente de datos directamente, algo similar a una función de validación de correo electrónico sería reutilizable. Se implementa en SQL.

Respuesta corta: depende. :)

MySQL escalará mejor a medida que aumentan los conjuntos de resultados. Francamente, tratar una base de datos como un repositorio de "datos tontos" es una pérdida de recursos ...

La capacidad de mantenimiento tiende a estar contaminada por la familiaridad. Si no está familiarizado con PHP, no sería su elección inicial para el mantenimiento, ¿o sí?

No me gusta reinventar la rueda. También me gusta usar la mejor herramienta posible para la tarea que se necesita hacer, así que:

Cuando puedo obtener el conjunto de resultados directamente de DB sin más procesamiento, lo hago; su caso es una consulta simple con una cláusula WHERE simple. Imagine lo que sucede cuando tiene 10 millones de usuarios y los obtiene a PHP, solo para necesitar 100, lo adivinó, es muy posible que su servidor web se bloquee
Cuando necesita obtener datos de 2 o más tablas a la vez, de nuevo, MySQL es mucho mejor que PHP
Cuando necesitas contar los registros, el DB es excelente
Tiendo a favorecer el procesamiento de nivel de aplicación a las restricciones FK
Además, tiendo a evitar los procedimientos almacenados, prefiriendo implementar esa lógica de negocios a nivel de aplicación (a menos, por supuesto, estamos hablando de grandes conjuntos de datos).

En conclusión, diría que su colega tiene razón en el caso presentado

Si pones la mitad de tu lógica en la base de datos y la otra mitad en el php, luego de 6 meses en la pista cuando realizas un cambio, te tomará el doble de tiempo descubrir qué está pasando.

Dicho esto, las consultas de la base de datos deben tener la lógica suficiente para que proporcionen a su php exactamente los datos que necesita . Si te encuentras recorriendo miles de registros mysql en tu código php, entonces estás haciendo algo mal. Sin embargo, en el otro extremo de la escala, si está ejecutando sentencias if / else en sus consultas de mysql, también está haciendo algo incorrecto (probablemente solo necesite reescribir su consulta).

Me mantendría alejado de los procedimientos almacenados. Si bien son un gran concepto en teoría, generalmente se puede lograr el mismo resultado en php con un tiempo de desarrollo mucho más rápido y también se tiene el beneficio adicional de saber dónde está toda la lógica.