Haciendo cálculos en MySQL vs PHP

Yo jugaría con las fortalezas de cada sistema.

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

Por otro lado, la mayoría de las plataformas de base de datos que he usado tienen una funcionalidad muy pobre para trabajar con valores individuales. Las cosas como el formato de fechas y la manipulación de cadenas simplemente apestan en SQL, es mejor que hagas ese trabajo en PHP.

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

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

Re:ejemplos específicos...

1. 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 se configuran alguna vez para diferentes zonas horarias (he visto que esto sucede). Imagina, por ejemplo, que tienes una createdDate columna con un valor predeterminado de getDate() que se aplica en la inserción por el DB . Si tuviera que insertar un registro entonces, usando una fecha generada en PHP (por ejemplo, date("Y-m-d", time() - 3600) , seleccione registros creados en la última hora, es posible que no obtenga lo que espera. En cuanto a la capa en la que debe hacer esto, preferiría la base de datos porque, como en el ejemplo, le permite usar valores predeterminados de columna.

2. Para la mayoría de las aplicaciones, haría esto en PHP. Combinar el nombre y el apellido suena simple hasta que te das cuenta de que a veces también necesitas saludos, títulos e iniciales del segundo nombre. Además, es casi seguro que terminará en una situación en la que desea un nombre de usuario, apellido Y una combinación de saludo + nombre + apellido. Concatenarlos en el lado de la base de datos significa que termina moviendo más datos, aunque en realidad es bastante menor.

3. Depende Como se indicó anteriormente, si alguna vez desea usarlos por separado, es mejor que, en cuanto al rendimiento, los extraiga por separado y los concatene cuando sea necesario. Dicho esto, a menos que los conjuntos de datos con los que trabaje sean enormes, probablemente haya otros factores (como, como menciona, la capacidad de mantenimiento) que tengan más influencia.

Algunas reglas generales:

• La generación de ID incrementales debería ocurrir en la base de datos.
• Personalmente, me gusta mi valor predeterminado aplicado por la base de datos.
• Al seleccionar, la base de datos debe hacer cualquier cosa que reduzca el número de registros.
• Suele ser bueno hacer cosas que reduzcan el tamaño del lado de la base de datos del conjunto de datos (como con el ejemplo de cadenas anterior).
• Y como dices; la ordenación, la agregación, las subconsultas, las uniones, etc. siempre deben estar en el lado de la base de datos.
• Además, no hemos hablado de ellos, pero los factores desencadenantes suelen ser malos/necesarios.

Hay algunas compensaciones principales a las que se enfrenta aquí y el equilibrio realmente depende de su aplicación.

Algunas cosas definitivamente, siempre, siempre deben hacerse en SQL. Excluyendo algunas excepciones (como las fechas) para muchas tareas, SQL puede ser muy torpe y puede dejarlo con lógica en lugares apartados. Al buscar en su base de código referencias a una columna específica (por ejemplo), es es fácil pasar por alto los contenidos 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 muy importante. 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 acceden directamente a la base de datos (por ejemplo, para informes o importaciones/exportaciones), se beneficiará de tener más lógica en la base de datos. Por ejemplo, si desea importar usuarios de otra fuente de datos directamente, algo así como una función de validación de correo electrónico sería reutilizable en SQL.

Respuesta corta:depende. :)