Hola,
cual es la diferencia entre MYSQL [standard ] y MYSQL [community] ?
El comprtamiento de las sentencias difiere?
| |||
Respuesta: MySQL standard VS MySQL community Por favor dime cuanto es el pago? Se deduce entonces que Standard es superior a [5.0.51a-community] ? ------------------------------------------------------ Resulta que esta sentencia: SELECT info FROM `table` WHERE date=now(); me devuelve excelentemente los valores con [4.1.22-standard] Y me devuelve empty con [5.0.51a-community]. Que será? Un BUG en [5.0.51a-community] ? O cómo decía inialmente: [5.0.51a-community] trabaja diferente? GRACIAS! |
| ||||
Respuesta: MySQL standard VS MySQL community No es necesariamente un bug. En MySQL 5.0.45-community-nt-log, esa función te devuelve un DateTime, por ejemplo: "2008-07-24 15:00:02". Obviamente, si el contenido del campo en cuestión no es exactamente el mismo, te devolverá NULL. El que funcione en MySQL 4.1.22 y no en MySQL 5.0.45 peude corresponder a los cambios entre versiones. Necesariamente si consideramos que el bug existe, es en la versión 4.1.22, ya que por lógica el momento ACTUAL y el de un campo ya almacenado nunca deberían coincidir... Respecto de los precios, eso lo tienes que resolver con MySQL... Fíjate en los representantes más cercanos que tengas.
__________________ ¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente... "El problema es la interfase silla-teclado." (Gillermo Luque) |
| |||
Respuesta: MySQL standard VS MySQL community Gracias, esta es una de las BD: Cita: Corro el SQL:CREATE TABLE IF NOT EXISTS `qqq` ( `id` mediumint(5) NOT NULL auto_increment, `info` varchar(255) NOT NULL default '', `problema` date NOT NULL default '0000-00-00', UNIQUE KEY `id` (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=3 ; -- -- Volcar la base de datos para la tabla `qqq` -- INSERT INTO `qqq` (`id`, `info`, `problema`) VALUES (1, 'row1', '2008-07-24'), (2, 'row2', '2008-07-24'); Cita: En 5.0.51a-community: MySQL ha devuelto un valor vacío (i.e., cero columnas). (La consulta tardó 0.0004 seg) SELECT * FROM `qqq` WHERE info = 'row1' AND problema = now( ) En 4.1.22-standard: Mostrando registros 0 - 0 (1 total, La consulta tardó 0.0005 seg) Crees de veras que la versión 4.1.22-standard tenga ese BUG? Danos algun ejemplo de que PUEDE HACERSE con standard que NO SE PUEDA con comunity |
| ||||
Respuesta: MySQL standard VS MySQL community Vamos desde atrás para adelante: 1. Las diferencias de performance y aplicación del Enterprise y del Community Server las debes ver en la página oficial del tema. Son demasiado extensas y específicas sobre determinadas funcionalidades del motor de MySQL para ponerlas en un post, además de no saber en realidad cuánto has profundizado tú en bases de datos como para poder darte una orientación correcta. No quiero extenderme en explicaciones que te puedan parecer obvias o en otras que requieren más conocimientos que los míos para darlas con precisión y que sean inteligibles. 2. Respecto del "bug" entre MySQL 5.0.45 y 4.0.22, el problema fue un bug de la 4.0.22 resuelto para la versión 5.0.45 que se puede describir de la siguiente forma: - MySQL es un motor de base de datos contextual. En ese sentido realiza (al igual que Oracle en algunos casos) cierto número de conversiones implícitas según la operación y los operadores, como es el caso de los manejos de las fechas y las horas. - Según el manual oficial de referencia de MySQL 4.0.22, el valor devuelto por NOW() es un datetime (de forma '0000-00-00 00:00:00'), pero considerando que estás comparándolo a un DATE, está haciendo una conversión implícita entre el datetime y el date, por lo cual la comparación daría TRUE desde el momento en que las FECHAS coinciden. La conversión se hace de DATETIME a DATE. - En el caso de MySQL 5.0.45, la conversión en estos casos debe ser explícita; si el formato de uno de los dos campos no coincide con el otro, toma el valor menor y lo lleva al formato mayor, es decir, de DATE a DATETIME (de esto estoy bien seguro porque lo uso en muchas consultas donde los campos de fecha y hora me llegan separados y uso ADDTIME() para obtener el DateTime); al hacer esta conversión el contenido del campo de la tabla pasa a ser '2008-07-24 00:00:00', con lo que sólo puede dar TRUE en un segundo preciso del día: la hora cero. Técnicamente hablando, es un problema de cómo operan las funciones entre las dos versiones. Entonces, si lo que quieres es que la consulta te devuelva TRUE, deberá ser:
Código:
Tip final: SELECT * FROM `qqq` WHERE info = 'row1' AND problema = DATE(now( )); En tu última frase, hablas en plural, por lo que pareciera que estoy respondiendo a un grupo de personas. Te recomiendo encarecidamente que en los foros solamente escribas tu. Si hay más participantes del trabajo, por favor que cada uno se inscriba por separado y postee por separado, porque de lo contrario no hay forma de saber a quién estoy respondiendo ni quien me está contestando. Gracias.
__________________ ¿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; 24/07/2008 a las 18:54 |
| |||
![]() Cita: SI, por supuesto!!! le estas ayudando a todo un grupo de usuarios de FDW!!!A todos los que léan este POST!!!!. Y te haz fajádo en la repuesta, esta buenísima!!!!. Gracias.!!!. Solo por CONFIRMAR: Entonces sí éra un BUG de la versión 4 ? De nuevo gracias. |
| ||||
Respuesta: MySQL standard VS MySQL community Si, era un bug del 4.0.22. Fijate en el link que te puse en el post. Allí está el detalle: http://dev.mysql.com/doc/refman/5.0/...cs-5-0-45.html. El primer bug resuelto es el que te digo.
__________________ ¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente... "El problema es la interfase silla-teclado." (Gillermo Luque) |
| |||
Respuesta: MySQL standard VS MySQL community Gracias. Entonces desde ahora: SELECT CURTIME(); // PARA LA HORA SELECT CURDATE(); // PARA LA FECHA SELECT YEAR(CURDATE()); // PARA EL AÑO O hay algun QUERY mejor? Para insertar en 3 campos AÑO-FECHA-HORA: ANTES: MYSQL_QUERY("INSERT INTO table VALUES (NOW(),NOW(),NOW()") AHORA: MYSQL_QUERY("INSERT INTO table VALUES (YEAR(CURDATE()),CURDATE(),CURTIME()") Así debemos insertar AÑO-FECHA-HORA ?? |
| ||||
Respuesta: MySQL standard VS MySQL community ¿Acaso tienes en la tabla tres campos, uno para año, otro para día y otro para hora? Eso me parece extremadamente ineficiente. Describe la tabla completa, a ver si se entiende correctamente.
__________________ ¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente... "El problema es la interfase silla-teclado." (Gillermo Luque) |
| |||
Respuesta: MySQL standard VS MySQL community Hola gnzsoloyo. Ok, puede ser ineficiente. Pero cuentanos: desde ahora: SELECT CURTIME(); // PARA LA HORA SELECT CURDATE(); // PARA LA FECHA SELECT YEAR(CURDATE()); // PARA EL AÑO O hay algun QUERY mejor? Para un ejemplo como este: Para insertar en 3 campos AÑO-FECHA-HORA: ANTES: MYSQL_QUERY("INSERT INTO table VALUES (NOW(),NOW(),NOW()") AHORA: MYSQL_QUERY("INSERT INTO table VALUES (YEAR(CURDATE()),CURDATE(),CURTIME()") Así debemos insertar AÑO-FECHA-HORA ?? Gracias, aunque es inéficiente, así se ha querido DIVIDIR la info. |
| ||||
Respuesta: MySQL standard VS MySQL community El campo "FECHA" es redundante respecto al campo "AÑO". Ambos contienen el año. Uno tendría un valor "2008" y el otro '2008-07-25', por ejemplo. Fuera de eso, yo pondría: [code] INSERT INTO tabla VALUES(YEAR(NOW()), DATE(NOW()), TIME(NOW())); [code] Cuestión de gustos. NOW() me devuelve un datetime, por lo que puedo extraer tod ala información de esa función. Respecto a la redundancia, recuerda que un byte de más en la longitud de un registro son Kilobytes de más en la tabla y en los índices, y Megabytes de más en las bases de datos. Nunca se debe poner una longitud mayor de la necesaria. Afecta en el largo plazo la performance de las consultas.
__________________ ¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente... "El problema es la interfase silla-teclado." (Gillermo Luque) |