[SOLUCIONADO] String se almacena en un campo Integer de una Tabla Mysql con el valor 0 (Cero)

[lne]

Importo empleados a una Tabla (Empleados) de Base de Datos (BD) Mysql. Permitiendo en el Sistema Web, especificar al USUARIO en qué columna se encuentra los campos Apellido, Nombre y Nº de documento (los demás campos de la Tabla son opcionales y se guardan con el valor por defecto).

El problema está cuando el USUARIO se equivoca en especificar las COLUMNAS. Es decir, cuando especifica la columna APELLIDO o NOMBRE por NUMERO_DOCUMENTO (almacenando el valor 0 "Cero").

La Tabla Empleados es la siguiente:

Código MySQL:

CREATE TABLE IF NOT EXISTS `empleados` (
  `id_empleado` mediumint(6) unsigned NOT NULL AUTO_INCREMENT,
  `apellido` varchar(50) COLLATE utf8_unicode_ci NOT NULL,
  `nombre` varchar(50) COLLATE utf8_unicode_ci NOT NULL,
  `codigo_postal` varchar(8) COLLATE utf8_unicode_ci DEFAULT NULL,
  `calle` varchar(50) COLLATE utf8_unicode_ci DEFAULT NULL,
  `numero` varchar(7) COLLATE utf8_unicode_ci DEFAULT NULL,
  `piso` varchar(2) COLLATE utf8_unicode_ci DEFAULT NULL,
  `departamento` varchar(4) COLLATE utf8_unicode_ci DEFAULT NULL,
  `numero_documento` int(8) unsigned NOT NULL,
  `numero_legajo` mediumint(8) unsigned DEFAULT NULL,
  `id_estado_empleado` tinyint(1) unsigned DEFAULT '1',
  `id_localidad` smallint(5) unsigned DEFAULT NULL,
  `id_puesto` smallint(5) unsigned DEFAULT NULL,
  `id_empresa` smallint(4) unsigned DEFAULT NULL,
  `id_sexo` tinyint(1) unsigned DEFAULT NULL,
  `fecha_nacimiento` date DEFAULT NULL,
  `fecha_alta` date DEFAULT NULL,
  `fecha_baja` date DEFAULT NULL,
  `codigo` varchar(32) COLLATE utf8_unicode_ci DEFAULT NULL,
  `id_origen_empleado` enum('1','2') COLLATE utf8_unicode_ci NOT NULL DEFAULT '2',
  PRIMARY KEY (`id_empleado`),
  KEY `id_estado_empleado` (`id_estado_empleado`),
  KEY `id_localidad` (`id_localidad`),
  KEY `id_puesto` (`id_puesto`),
  KEY `id_empresa` (`id_empresa`),
  KEY `id_sexo` (`id_sexo`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=53 ;
 

La siguiente CONSULTA 1 (obtiene el resultado deseado, el ERROR):

Código MySQL:

INSERT INTO `audical`.`empleados` (`id_empleado`, `apellido`, 
`nombre`, `codigo_postal`, `calle`, `numero`, `piso`, `departamento`, 
`numero_documento`, `numero_legajo`, `id_estado_empleado`, 
`id_localidad`, `id_puesto`, `id_empresa`, `id_sexo`, `fecha_nacimiento`, 
`fecha_alta`, `fecha_baja`, `codigo`, `id_origen_empleado`) 
VALUES (NULL, 'Cuello', '36123456', NULL, NULL, NULL, NULL, NULL, 'Juana', 
NULL, '1', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, '2');
 

Retornando el siguiente ERROR:
1 fila insertada.
La Id de la fila insertada es: 59
Warning: #1366 Incorrect integer value: 'Juana' for column 'numero_documento' at row 1

En cambio, si utilizo esta CONSULTA 2 (que es la que utilizo en el Sistema):

Código MySQL:

INSERT INTO `audical`.`empleados` (`apellido`, `nombre`, 
`numero_documento`) 
VALUES ('Cuello', '36123456', 'Juana');
 

Retornando que la consulta se ejecutó exitosamente, insertando el registro:
1 fila insertada.
La Id de la fila insertada es: 60 ( La consulta tardó 0.0532 seg )

¿Por qué la CONSULTA 2 no devuelve ERROR como la CONSULTA 1?

Desde ya muchas gracias..

[gnzsoloyo]

¿Por qué la CONSULTA 2 no devuelve ERROR como la CONSULTA 1?

Tu pregunta tiene una respuesta bastante obvia, perdona que te lo diga.
La primera consulta devuelve un error porque el orden de los datos está mal, y terminas enviando el nombre en la posición donde debe entrar un número.
Estos son los datos que quieres ingresar, según el orden que pones:

Código MySQL:

`id_empleado`, 
`apellido`, 
`nombre`, 
`codigo_postal`, 
`calle`, 
`numero`, 
`piso`, 
`departamento`, 
`numero_documento`, 
`numero_legajo`, 
`id_estado_empleado`, 
`id_localidad`, 
`id_puesto`, 
`id_empresa`, 
`id_sexo`, 
`fecha_nacimiento`, 
`fecha_alta`, 
`fecha_baja`, 
`codigo`, 
`id_origen_empleado`
 

Este es el orden de los datos que envías en el VALUE:

Código MySQL:

NULL, 
'Cuello', 
'36123456', 
NULL, 
NULL, 
NULL, 
NULL, 
NULL, 
'Juana', 
NULL, 
'1', 
NULL, 
NULL, 
NULL, 
NULL, 
NULL, 
NULL, 
NULL, 
NULL, 
'2'
 

¿Puedes ver que no condicen la columna Nº 9, con el dato Nº 9?

Bueno, ese es el problema.

[leonardo_josue]

Hola lne:

Como observación adicional: En realidad no es un ERROR el que te está apareciendo en la consulta, sino un mensaje WARNING, o de advertencia... observa que en realidad el insert sí se ejecuta:

Código:

1 fila insertada.
La Id de la fila insertada es: 59
Warning: #1366 Incorrect integer value: 'Juana' for column 'numero_documento' at row 1

El detalle está en que el campo numero_documento es de tipo entero y ty estás asignando un valor tipo cadena:

Para el primer caso:

Código:

`id_empleado`,       NULL,
`apellido`,          'Cuello',
`nombre`,            '36123456',
`codigo_postal`,     NULL,
`calle`,             NULL,
`numero`,            NULL,
`piso`,              NULL,
`departamento`,      NULL,
`numero_documento`,  'Juana',
`numero_legajo`,     NULL,
`id_estado_empleado`,'1',
`id_localidad`,      NULL,
`id_puesto`,         NULL,
`id_empresa`,        NULL,
`id_sexo`,           NULL,
`fecha_nacimiento`,  NULL,
`fecha_alta`,        NULL,
`fecha_baja`,        NULL,
`codigo`,            NULL,
`id_origen_empleado` '2'

En el segundo caso, es lo mismo, aunque con menos campos:

Código:

`apellido`, 	'Cuello', 
`nombre`, 	'36123456', 
`numero_documento`	'Juana' 

Saludos
Leo.

[lne]

Me están entendiendo mal, EL ORDEN DE LOS CAMPOS ESTÁN ASÍ A PROPÓSITO "para representar el caso de que un USUARIO especifique mal el orden de las COLUMNAS". Yo quiero que en caso de que se intente ingresar un nº de documento(integer) en otro campo(string) me devuelva un error para poder informarlo al usuario. El problema es que cuando hago la consulta más corta (CONSULTA 2) MYSQL no devuelve ningún error, sino que guarda el valor 0 (cero) cuando no debería dejarme insertar el registro porque el tipo dato es OBVIAMENTE incorrecto para el campo especificado.
Mi idea es tratar de evitar de validar con PHP, y de hacerlo por MYSQL.

[leonardo_josue]

Hola lne:

No te estamos entiendo mal, sino que no has sabido explicarte buen... eso muy distinto y te recomiendo que tengas cuidado con ese tipo de comentarios.

Checa esta liga:

http://dev.mysql.com/doc/refman/5.0/...-sql-mode.html

y aquí estaría el ejemplo de lo que debes hacer:

Código MySQL:

mysql> SET SQL_MODE = '';
Query OK, 0 rows affected (0.00 sec)
 
mysql> INSERT INTO `empleados` (`apellido`, `nombre`, `numero_documento`)
    -> VALUES ('Cuello', '36123456', 'Juana');
Query OK, 1 row affected, 1 warning (0.02 sec)
 
mysql> SELECT `apellido`, `nombre`, `numero_documento` FROM empleados;
+----------+----------+------------------+
| apellido | nombre   | numero_documento |
+----------+----------+------------------+
| Cuello   | 36123456 |                0 |
+----------+----------+------------------+
1 row in set (0.00 sec)
 
mysql> SET SQL_MODE = 'TRADITIONAL';
Query OK, 0 rows affected (0.00 sec)
 
mysql> INSERT INTO `empleados` (`apellido`, `nombre`, `numero_documento`)
    -> VALUES ('Cuello', '36123456', 'Juana');
ERROR 1366 (HY000): Incorrect integer value: 'Juana' for column 'numero_document
o' at row 1
mysql> SELECT `apellido`, `nombre`, `numero_documento` FROM empleados;
+----------+----------+------------------+
| apellido | nombre   | numero_documento |
+----------+----------+------------------+
| Cuello   | 36123456 |                0 |
+----------+----------+------------------+
1 row in set (0.00 sec)
 

En el primer caso lo toma como Warning y te deja hacer el insert... en segundo marca error.

Saludos
Leo.

[gnzsoloyo]

Vamos a agregar algunos detalles conceptuales, que tienen que ver con buenas prácticas de desarrollo:

- Ningún desarrollador en su sano juicio deja que sea el usuario el que decida en qué orden serán puestos en un INSERT a la base los datos, sin previamente validar todos y cada uno de ellos. ¿Nunca escuchaste que el mayor problema de todo software es la interface silla-teclado?

- Nunca se hace una interfaz donde haya N formas de ordenar los datos de una tabla, porque entonces tendrás 2x10^n formas posibles de meter la pata (la formula es un chiste, pero la idea es esa).

Otra observación, adjunta a lo de Leo, es que tienes que entender que MySQL trabaja también en forma contextual, y eso hace que bajo ciertas circunstancias, jamás podrías haber detectado ni siquiera un warning. Sería el caso de que en lugar de poner un nombre, hubiese ingresado "109", como cadena de texto. MySQL simplemente hubiese convertido eso a número y tu ni te enteras.

Finalmente:

Mi idea es tratar de evitar de validar con PHP, y de hacerlo por MYSQL.

Eso es un error total, muy común en los programadores: No quieren tener que trabajar...
NO. No debes derivar una responsabilidad que es propia del lenguaje de programación (lógica de capa de negocios) a la base de datos, por al menos tres razones:

1) Los lenguajes de programación tienen mucha más capacidad para hacer tareas de validación, entre otras cosas porque es en programación donde controlas los formularios de ingreso de datos. ¿Escuchaste la expresión "a prueba de tontos"? Bueno, esa es la meta de todo buen desarrolador.

2) Poner las validaciones de ese nivel en la base de datos es dedicar tiempo de procesamiento a tareas complementarias, y desperdiciar la potencia de los DBMS en cosas para las que no han sido diseñados. El motor de base de datos está optimizado para consultas, no para validar cosas que debería recibir verificadas. Lo que sí existen es consultas de validación, que se implementan en la capa de acceso a datos, específicamente para eso, pero no son consultas dinámicas.

3) Transferir "datos basura" es un enorme desperdicio de recursos de red, que deberás eventualmente pagar en performance. Si vas a mandar datos no validados a la base, eso desperdicia accesos, red, y overhead de red, y tarde o temprano lo vas a lamentar. Además, los hosting te cobran extra si superas la cuota de transferencia de datos fijada, oprlo que te imaginarás que en tu modelo, sería desastroso.

No trates de inventar la rueda de nuevo. Por algo esas tareas no las hace así ninguna aplicación medianamente importante y estable: Porque no es eficiente.

[lne]

Muchas gracias por sus comentarios..