¿Es generalmente mejor ejecutar funciones en el servidor web, o en la base de datos?Funciones en mysql o php
por ejemplo: INSERT INTO ejemplo (hash) VALOR (MD5 ('hola'))
o
INSERT INTO ejemplo (hash) VALOR ('5d41402abc4b2a76b9719d911017c592')
Ok por lo que es una realidad ejemplo trivial, pero para la escalabilidad cuando un sitio crece en varios sitios web o servidores de bases de datos, ¿dónde es mejor "hacer el trabajo"?
Intento pensar en la base de datos como el lugar para persistir solo y poner todo el código de abstracción en otro lugar. Las expresiones de base de datos ya son lo suficientemente complejas sin agregarles funciones.
Además, el optimizador de consultas tropezar con ninguna expresión con las funciones que si alguna vez llegar a querer hacer algo así como "SELECT .... donde MD5 (xxx) = ..."
y base de datos funciones no son muy portátiles en general.
Personalmente, trato de mantener la base de datos tan simple (al mínimo) con Insertar, Actualizar, Eliminar sin tener demasiada función que pueda usarse en el código. Stored Proc es el mismo, contiene solo tareas que están muy cerca de los datos de persistencia y no relacionados con la lógica comercial.
Me gustaría poner el MD5 fuera. Esto permitirá que Met tenga esta "manipulación de datos" fuera del alcance de almacenamiento de la base de datos.
embargo, su ejemplo es bastante "fácil" y no creo que es malo tenerlo dentro ...
Creo que la mayoría de las veces, usted va a querer salir de la manipulación de datos a el servidor web pero, si desea procesar las bases de datos con respecto a tablas, relaciones, etc., vaya a la base de datos.
Personalmente presiono a mi empresa para actualizar nuestro servidor MySQL a 5.0 para que pueda comenzar a aprovechar los procedimientos (lo que está matando a algunos sitios que administramos).
Intento usar funciones en mi lenguaje de scripting siempre que se requieran cálculos como este. Mantengo el uso de mi función SQL al mínimo, por varias razones.
La razón principal es que mi base de datos SQL es responsable de alojar varios sitios web. Si el servidor SQL se empantanara con las solicitudes de un sitio, afectaría negativamente al resto. Esto es aún más importante a tener en cuenta si está trabajando en un servidor compartido, por ejemplo, aunque en este caso tiene poco control sobre lo que hacen los otros usuarios.
La razón secundaria es que me gusta que mi código SQL sea lo más portátil posible. Ni siquiera quiero probar para contar los diferentes sabores de SQL que existen, por lo que trato de mantener las funciones (especialmente las extensiones no estándar) fuera de mi código SQL, a excepción de cosas como SUM o MIN/MAX.
Supongo que lo que digo es que SQL está diseñado para almacenar y recuperar datos, y debe mantenerse para tal fin. Utilice su idioma de servicio elegido para realizar cualquier cálculo de antemano y mantenga su código SQL portátil.
Utilice su base de datos como medio para conservar y mantener la integridad de los datos. Y deja la lógica de negocios fuera de ella.
Si pone la lógica comercial, cualquiera de ellas, en su base de datos, está haciendo que sea más complejo administrarla y mantenerla en el futuro.
Al igual que las otras respuestas hasta ahora, prefiero mantener toda la lógica comercial en un solo lugar. Es decir, mi lenguaje de aplicación. (Más específicamente, en el modelo de objetos, si hay uno presente, pero no todo el código es OO)
Sin embargo, si mira alrededor de StackOverflow para (my) preguntas etiquetadas sql acerca de si usar SQL en línea o procedimientos almacenados , encontrará que la mayoría de las personas que responden a ellos están totalmente a favor de usar procesos almacenados siempre que sea posible, incluso para las consultas más triviales. Es posible que desee verificar algunas de esas preguntas para ver algunos de los argumentos que favorecen el otro enfoque.