Retorno de una Funcion MySql que no sea NULL

[betodaniel61]

Buenas Tardes:

Tendo el siguiente problema:
Desarrolle un Store_Function en Mysql el cual me devuelve el saldo de un Usuario, el tema es que cuando no encuentra registros en CuentaCorriente me devuelve Valor NULL aunque le haya puesto por default 0.
Yo necesitaría que el valor que me devuelva en tal caso sea 0

Les paso el codigo de la funcion por si pueden ayudarme:

DELIMITER $$

DROP FUNCTION IF EXISTS `sf_saldo` $$
CREATE DEFINER=`root`@`localhost` FUNCTION `sf_saldo`(u int) RETURNS decimal(12,2)
begin
declare Saldo decimal(12,2) default 0;
set Saldo=0;
select sum( if(signo="+",importe,if(signo="-",importe*-1,0)) ) into Saldo from cuentacorriente left join tipomovimientos using(idtipomovimiento) where idusuario=u;
return(Saldo);
end $$

DELIMITER ;

Muchas Gracias

[gnzsoloyo]

Código MySQL:

DELIMITER $$
 
DROP FUNCTION IF EXISTS `sf_saldo` $$
CREATE FUNCTION `sf_saldo`(u INT) RETURNS DECIMAL(12,2)
BEGIN
  DECLARE Saldo DECIMAL(12,2) DEFAULT 0;
  SET Saldo=0;
  SELECT SUM(IF(signo="+",importe,IF(signo="-",importe*-1,0)) ) INTO Saldo FROM cuentacorriente LEFT JOIN tipomovimientos USING(idtipomovimiento) WHERE idusuario=u;
  RETURN IFNULL(Saldo, 0.0);
END$$
 
DELIMITER ;
 

Sigo insistiendo en que el modelo de datos que estás usando está mal diseñado. Ni siquiera me contestaste el planteo (http://www.forosdelweb.com/f86/funci...-mysql-905258/)

[betodaniel61]

Muchas Gracias gnzsoloyo por tu ayuda, asi me funciono bien.

Con respecto al calculo del saldo o a la visualizacion de movimientos de una cuenta corriente, relacionada con una tabla de tipos de movimientos no me parece que sea tan inconveniente porque al mostrarselo al usuario se puede mostrar como lo requiera el usuario.
Distinto seria en una aplicación de Contabilidad, la cual necesita de muchas operaciones y sumas por columnas.
En una aplicacion de cuentas corrientes o movimientos de stock no me parece tan mal.

Es mi simple opinion, igualmente acepto tu planteo. y Muchisimas Gracias por toda la ayuda que me brindas.

[gnzsoloyo]

El usuario no tiene por qué decidir sobre los aspectos internos del diseño de la base. Sólo necesita obtener lo que quiere. Es tuya la responsabilidad como DBA establecer cuál es el diseño adecuado para cumplir los requerimientos del cliente.
El problema es que centrarte en los procesos para realizar un diseño pobre no sólo le quita eficiencia, sino que además comprometes la portabilidad, la flexibilidad del sistema y aumentas la dependencia de la base de un sólo proceso, en lugar de plantear un diseño con visión de futuro, que pueda responder a cosas que aún no ven, pero pueden requerirse.
Uno de los consejos que siempre dan los profesores de BB.DD. es que una base de datos no se diseña ni para un proceso, ni para el uso presente, sino para el uso que se les dará más adelante.
Si diseñas para una aplicación, cuando se requieran cambios formales o visuales en esos mismos procesos, tendrás que volver al modelo para rediseñarlo.

Consejo: Haz las cosas bien desde el inicio, los parches y las migraciones son terribles.

[betodaniel61]

Ok, con repecto al usuario yo me referia a la forma que lo necesitaba visualizar.
y por lo demas es para tenerlo en cuenta.
Muchas Gracias