Cita: luego de recuperar los registros que requieras
No, pancho2413, no es eso lo que digo. Todo conjunto de datos en los que se realicen operaciones de suma, producto, estadísticas o de cualquier tipo semejante, son perfectamente viables en SQL. Lo que
no tiene ningún sentido ni utilidad es guardar los resultados, ya que la operación de generarlos se realiza al mismo tiempo que se hace la consulta, y el
almacenarlos no produce ningún tipo de ahorro de recursos destacable.
Lo que decimos, tanto huesos52 como yo es que lo que debe hacer en la aplicación es validar los ingresos realizados por los usuarios. Eso. Nada más. Porque para ello los lenguajes tienen mejores recursos.
Por citar algunos casos:
- Cuando se requiere que un campo en un formulario sea numérico solamente, son como mucho media docena de líneas de código (i no usas un control prediseñado para ello), mientras que hacerlo en la base requiere más tiempo y recursos.
- Hacer que un campo numérico sólo pueda ingresar un rango de A a B, es darle los límites al control de texto donde se ingresan esos datos.
- Limitar que un combo de selección sólo pueda contener sólo un valor entre un conjunto específico de valores solamente requiere al inicio una consulta a la base de una tabla de datos fija, y luego se sigue usando el mismo conjunto en todas las operaciones, sin más consultas.
- Hacer que un dato alfanumérico tenga un formato predeterminado, requiere el uso de un control que use máscara de datos.
- Validar un dato de fecha, solamente requiere de otro tipo de control, y los límites del rango son propiedades del mismo.
Podría seguir así indefinidamente, pero supongo que con eso es suficiente. La idea es que los lenguajes actuales cuentan con muchos recursos y muy eficientes para permitir programar interfases de ingreso de datos que no permitan ingresar datos erróneos. No necesitas la base de datos para eso.