De acuerdo, lo abordaré: soy un mejor codificador que en las bases de datos, y me pregunto dónde están las ideas sobre "mejores prácticas" sobre el tema de hacer cálculos "simples" en la consulta SQL vs. el código, como este ejemplo de MySQL (¡no lo escribí, solo tengo que mantenerlo!) - Esto devuelve el nombre de usuario y la edad de los usuarios desde el último evento.
SELECT u.username as user,
IF ((DAY(max(e.date)) - DAY(u.DOB)) < 0 ,
TRUNCATE(((((YEAR(max(e.date))*12)+MONTH(max(e.date)))
-((YEAR(u.DOB)*12)+MONTH(u.DOB)))-1)/12, 0),
TRUNCATE((((YEAR(max(e.date))*12)+MONTH(max(e.date))) -
((YEAR(u.DOB)*12)+MONTH(u.DOB)))/12, 0)) AS age
FROM users as u
JOIN events as e ON u.id = e.uid
...En comparación con hacer el levantamiento "pesado" en el código:
Consulta:
SELECT u.username, u.DOB as dob, e.event_date as edate
FROM users as u
JOIN events as e ON u.id = e.uidcódigo:
function ageAsOfDate($birth, $aod)
{ //expects dates in mysql Y-m-d format...
list($by,$bm,$bd) = explode('-',$birth);
list($ay,$am,$ad) = explode('-',$aod);
//Insert Calculations here
...
return $Dy; //Difference in years
}
echo "Hey! ". $row['user'] ." was ". ageAsOfDate($row['dob'], $row['edate']) . " when we last saw him."; Estoy bastante seguro de que en un caso simple como este no habría mucha diferencia (aparte de la sensación de horror cuando tengo que hacer cambios en consultas como la primera), pero creo que aclara lo que yo ' Estoy buscando.
¡Gracias!
Respuestas:
Desea realizar todas las operaciones basadas en conjuntos en la base de datos por motivos de rendimiento. Entonces funciones de agregación, funciones de clasificación, uniones, etc.
Este cálculo de edad, lo haría en código. La única razón por la que podría hacer algo como esto en una consulta de base de datos es si requiriera muchas columnas que de otro modo no seleccionaría y que en realidad podrían ser suficientes datos para ralentizar significativamente mi consulta. Seleccionar algunos valores enteros no hará una diferencia significativa de rendimiento. E incluso si hace una diferencia de rendimiento moderada, estaré predispuesto a mantener esta lógica en el código de la aplicación.
fuente
Cada caso es diferente
Es la lógica ...
En este caso, podría usar una columna calculada y persistente en la base de datos
Podría ser peor: podría tener esto en la base de datos:
fuente
Básicamente, debe observar dos cosas: uso de CPU y tráfico de red. No debe generar respuestas enormes, transferirlas a través de la red y luego resumirlas en la interfaz, ya que la base de datos puede hacerlo mucho mejor.
Para la manipulación de datos es un intercambio de. Si la base de datos gasta una cantidad comparable de ciclos de CPU en su código frontend haciendo lo mismo, dado que la cantidad de datos transferidos es más o menos equivalente), entonces no importa dónde. Luego, hágalo donde tenga la mayor experiencia en programación. Con frecuencia, puede obtener un camino MUY largo con una selección cuidadosa y eso podría ser muy útil.
fuente
Usted mencionó uno: área de especialización. Quizás la estructura de la base de datos no sea demasiado intensa, por lo que decide descargar parte del desarrollo de la lógica a un miembro del equipo que esté más centrado en la base de datos. Puede que no sea lo ideal, pero si tienes poco tiempo ...
El hardware de la base de datos tiene significativamente más recursos que otros servidores y no puede cambiar esto. Esto puede no aplicarse a esta situación específica, pero puede ser necesario considerarlo.
Hay otras aplicaciones que pueden necesitar la lógica fuera de su código. Es posible que algunas herramientas de redacción de informes no puedan utilizar un servicio web o una API. Puede duplicar la lógica o si cree que los requisitos pueden diferir.
fuente
Siempre me equivoco al poner tanto procesamiento en la base de datos. Su sintaxis anterior también podría escribirse con funciones DB que serían IMO, una solución muy limpia.
fuente