Ver Mensaje Individual
  #7 (permalink)  
Antiguo 05/10/2010, 16:05
Avatar de gnzsoloyo
gnzsoloyo
Moderador criollo
 
Fecha de Ingreso: noviembre-2007
Ubicación: Actualmente en Buenos Aires (el enemigo ancestral)
Mensajes: 23.324
Antigüedad: 17 años
Puntos: 2658
Respuesta: Debería usar un Stored Procedure?

Vamos a algunos detalles:

1) Cuando haces una inserción de este tipo, en el que se ven afectadas más de una tabla, es conveniente usar transacciones, de modo que si algo falla, se deshagan todas las inserciones (cuestiones de consistencia).

2) Las variables de entrada no se usan con "@". Eso es de SQL Server (Microsoft) y no de MySQL. Las variables se usan simplemente declarandolas en el prototipo y usandolas con su nombre.

3) Las variables con "@" son variables de usuario y siguen existiendo y con su valor mientras dure la conexión. No es conveniente usarlas si no es estrictamente necesario precisamente por su permanencia, y cada vez que se las invoca deben ser inicializadas para evitar que guarden basura. Son muy útiles en cierto tipo de operaciones, pero no es buena prática usarlas en el prototipo de los SP, entre otras cosas porque si por alguna razón dos SP distintos que usan la misma variable son invocados por el mismo usuario en la misma sesión (threads de ejecución diferentes), el cambio de valor de la variable en un thread afectará el valor de la variable en el otro thread, simplemente porque apuntan a lo mismo...

4) Las variables no deben bajo ninguna circunstancia tener el mismo nombre de campos, tablas, bases o cualquier otro objeto de base de datos, porque el parser confundirá los objetos, ya que jerarquiza los mismos y en ese caso una tabla o un campo tienen mayor jerarquía que una variable, en consecuencia intentará acceder al campo o tabla y no a la variable, lo que puede dar lugar a errores aleatorios.

Este sería un modelo, basado en tu ejemplo:
Código MySQL:
Ver original
  1. CREATE PROCEDURE nuevoUsuario (
  2.   IN vuser_id int,
  3.   IN vuser_login varchar(25),
  4.   IN vuser_pass varchar(30),
  5.   IN vuser_activation_key varchar(40),
  6.   IN vuser_name varchar(30),
  7.   IN vuser_mail varchar(45),
  8.   IN vuser_birthday date,
  9.   IN vuser_sexo char(1),
  10.   IN vuser_pais smallint,
  11.   IN vfecha_registro timestamp,
  12.   IN vip_registro varchar(15))
  13.  
  14.  
  15.  
  16.   INSERT INTO tbl_user(
  17.     user_login,
  18.     user_pass,
  19.     user_activation_key)
  20.   VALUES(
  21.     vuser_login,
  22.     vuser_pass,
  23.     vuser_activation_key);
  24.  
  25.   INSERT INTO tbl_user_personal(
  26.     vuser_id,
  27.     vuser_name,
  28.     vuser_mail,
  29.     vuser_birthday,
  30.     vuser_sexo,
  31.     vuser_pais)
  32.   VALUES (
  33.     vuser_id,
  34.     vuser_name,
  35.     vuser_mail,
  36.     vuser_birthday,
  37.     vuser_sexo,
  38.     vuser_pais);
  39.  
  40.   INSERT INTO tbl_registro (
  41.     vuser_id,
  42.     vfecha_registro,
  43.     vip_registro)
  44.   VALUES (
  45.     vuser_id,
  46.     NOW(),
  47.     vip_registro);
  48.  
  49.  

Es de buenas prácticas Poner el sentido de entrada/salida de las variables, por más que el IN sea implícito. Facilita cualquier análisis rápido y además de ese modo no te olvidas de poner los OUT o INOUT cuando corresponden.
__________________
¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente...
"El problema es la interfase silla-teclado." (Gillermo Luque)

Última edición por gnzsoloyo; 05/10/2010 a las 16:14