On Wed, Apr 28, 2004 at 06:17:07PM -0400, Rodrigo Flores wrote: Hola,
> calza Mysql dentro de las Bases de Datos relacionales, tal vez deber??a > preguntarme si es verdaderamente una BD. La respuesta es no. Primera referencia es "MySQL gotchas", http://sql-info.de/mysql/gotchas.html Segundo, la gente cree que "tener transacciones" es suficiente. Esto no es asi; hay muchos otros aspectos a considerar, sobre todo si las transacciones son brujas. Por ej. si tienes tablas InnoDB y tablas MyISAM mezcladas, y en una transaccion haces cambios a ambos tipos de tablas, al hacer ROLLBACK los cambios se deshacen en las tablas InnoDB pero no las MyISAM; el estado es inconsistente al final. Y cuidado, porque si en la declaracion de una tabla se te olvida poner "type=innodb", la tabla no sera transaccional, no se te avisara de esto, las transacciones se ejecutaran aparentemente con exito pero al hacer rollback no pasa lo que tu esperas ... en resumen puede pasar cualquier cosa. Idem con la integridad referencial: si tu declaras una tabla con llaves foraneas pero no es InnoDB, nadie te va a informar que la llave foranea no esta siendo validada. Ojo con ingresar fechas 31 de febrero; el servidor las acepta y tu no sabes que diablos metio ahi dentro. Uno podria decir que es culpa de la aplicacion, pero lo cierto es que el sistema debe hacer chequeos. Idem con numeros demasiado grandes y otras cosas raras. Trata de calcular 123456789012345678901234567890 % 123; MySQL te dira 58. Pero la respuesta correcta es 117. WTF!? i.e.: no puedes confiar que MySQL te entregue respuestas correctas. Sobre el rendimiento: mucho se dice que MySQL es mas rapido, pero no te dicen que MySQL es mas rapido con tablas MyISAM, y que con tablas InnoDB la cosa es mucho mas lenta. Ahora tambien estan anunciando un "MySQL cluster", pero nadie dice que el cluster es un tipo especial de tabla y no puedes tener un cluster con tablas InnoDB (==> no puedes tener cluster _y_ transacciones _y_ rendimiento ... escoge solo una). En fin ... puras pifias ocultas, que ellos nunca te mencionan. MySQL es tan limitado en la sintaxis de consultas, que terminas haciendo muchas cosas en la aplicacion que te sale mucho mas rapido hacer en SQL (y el servidor de BD automaticamente te entrega resultados correctos, te evitas corregir bugs que surjan en tu codigo, y te ahorras muchas lineas de codigo!) Consecuencia de esto es que como tienes que hacer cosas tu mismo, las respuestas de la BD pueden venir mas rapido, pero tu pierdes mas tiempo procesandolas, y la aplicacion, que es lo que importa, es mas lenta. Otra cosa a tener en cuenta es que MySQL no es software libre. Es simplemente software comercial, que para algunas circunstancias te lo dejan usar gratis bajo licencia GPL, nada mas. Es igual que Microsoft aca: en la casa te lo dejan usar gratis (copia ilegal), pero la empresa tiene que pagarlo. Y olvidate que vas a tener voz y voto en el desarrollo futuro; si ellos no quieren hacer algo que necesites, estas frito. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "Before you were born your parents weren't as boring as they are now. They got that way paying your bills, cleaning up your room and listening to you tell them how idealistic you are." -- Charles J. Sykes' advice to teenagers From [EMAIL PROTECTED] Wed Apr 28 20:31:05 2004 From: [EMAIL PROTECTED] (Joel A. Iturra) Date: Wed Apr 28 20:31:57 2004 Subject: otra duda In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> On Wednesday 28 April 2004 20:19, Alvaro Herrera wrote: > On Wed, Apr 28, 2004 at 06:17:07PM -0400, Rodrigo Flores wrote: > > Hola, > > > calza Mysql dentro de las Bases de Datos relacionales, tal vez deber??a > > preguntarme si es verdaderamente una BD. > > La respuesta es no. no voy a discutir eso, pero.... > > Primera referencia es "MySQL gotchas", > http://sql-info.de/mysql/gotchas.html > > Segundo, la gente cree que "tener transacciones" es suficiente. Esto no > es asi; hay muchos otros aspectos a considerar, sobre todo si las > transacciones son brujas. Por ej. si tienes tablas InnoDB y tablas > MyISAM mezcladas, y en una transaccion haces cambios a ambos tipos de > tablas, al hacer ROLLBACK los cambios se deshacen en las tablas InnoDB > pero no las MyISAM; el estado es inconsistente al final. Y cuidado, > porque si en la declaracion de una tabla se te olvida poner > "type=innodb", la tabla no sera transaccional, no se te avisara de esto, > las transacciones se ejecutaran aparentemente con exito pero al hacer > rollback no pasa lo que tu esperas ... en resumen puede pasar cualquier > cosa. pero eso es obvio poh alvaro, si las transacciones estan solo para innodb en mysql, no puedes esperar que funcione en otro tipo de tablas. Osea, si el que esta haciendo la cuestion no tiene clara la diferencia, no es culpa de mysql > > Idem con la integridad referencial: si tu declaras una tabla con llaves > foraneas pero no es InnoDB, nadie te va a informar que la llave foranea > no esta siendo validada. por eso cuando definas tus tablas, debes asegurarte que todas sean innodb, de lo contrario es como querer que vuele un auto (solo un ejemplo) > Ojo con ingresar fechas 31 de febrero; el servidor las acepta y tu no > sabes que diablos metio ahi dentro. Uno podria decir que es culpa de la > aplicacion, pero lo cierto es que el sistema debe hacer chequeos. Idem > con numeros demasiado grandes y otras cosas raras. Trata de calcular > 123456789012345678901234567890 % 123; MySQL te dira 58. Pero la > respuesta correcta es 117. WTF!? i.e.: no puedes confiar que MySQL te > entregue respuestas correctas. bugs los tiene cualquiera no ?? y no son medios rebuscados esos ejemplos ?? > Sobre el rendimiento: mucho se dice que MySQL es mas rapido, pero no te > dicen que MySQL es mas rapido con tablas MyISAM, y que con tablas InnoDB > la cosa es mucho mas lenta. Ahora tambien estan anunciando un "MySQL > cluster", pero nadie dice que el cluster es un tipo especial de tabla y > no puedes tener un cluster con tablas InnoDB (==> no puedes tener > cluster _y_ transacciones _y_ rendimiento ... escoge solo una). ahi cada uno ve donde le aprieta el zapato, si se puede vivir con eso, cual es el problema ?? > En fin ... puras pifias ocultas, que ellos nunca te mencionan. pocas son las empresas que dicen donde estan sus debilidades (punto a favor de pgsql) >[....] respondiendo la pregunta original, yo diria que "depende". En todo caso concuerdo que si aun no han escogido una db y el asunto a desarrollar es grande (complejo), mejor tirarse por postgresql. -- Joel A. Iturra (1)(718)823-3904 From [EMAIL PROTECTED] Wed Apr 28 22:36:27 2004 From: [EMAIL PROTECTED] (Alvaro Herrera) Date: Wed Apr 28 22:51:41 2004 Subject: otra duda In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> On Wed, Apr 28, 2004 at 08:31:05PM -0400, Joel A. Iturra wrote: Joel, > > Por ej. si tienes tablas InnoDB y tablas > > MyISAM mezcladas, y en una transaccion haces cambios a ambos tipos de > > tablas, al hacer ROLLBACK los cambios se deshacen en las tablas InnoDB > > pero no las MyISAM; el estado es inconsistente al final. Y cuidado, > > porque si en la declaracion de una tabla se te olvida poner > > "type=innodb", la tabla no sera transaccional, no se te avisara de esto, > > las transacciones se ejecutaran aparentemente con exito pero al hacer > > rollback no pasa lo que tu esperas ... en resumen puede pasar cualquier > > cosa. > > pero eso es obvio poh alvaro, si las transacciones estan solo para innodb en > mysql, no puedes esperar que funcione en otro tipo de tablas. Osea, si el que > esta haciendo la cuestion no tiene clara la diferencia, no es culpa de mysql Si, para mi y para ti puede ser obvio, pero si quiere llamarse "transaccional" al menos deberia mandar un mensaje feo o tirar un error cuando en una transaccion se involucra una tabla no transaccional. O derechamente, dado que se supone que el sistema es transaccional, no deberian existir los tipos de tablas no transaccionales! > > Idem con la integridad referencial: si tu declaras una tabla con llaves > > foraneas pero no es InnoDB, nadie te va a informar que la llave foranea > > no esta siendo validada. > > por eso cuando definas tus tablas, debes asegurarte que todas sean innodb, de > lo contrario es como querer que vuele un auto (solo un ejemplo) Me acuerdo haber oido que si tenias MySQL compilado sin tablas InnoDB (versiones antiguas) y creabas una tabla con tipo InnoDB, el motor la cambiaba a MyISAM y no te daba ninguna indicacion de esto! > > Ojo con ingresar fechas 31 de febrero; el servidor las acepta y tu no > > sabes que diablos metio ahi dentro. Uno podria decir que es culpa de la > > aplicacion, pero lo cierto es que el sistema debe hacer chequeos. Idem > > con numeros demasiado grandes y otras cosas raras. Trata de calcular > > 123456789012345678901234567890 % 123; MySQL te dira 58. Pero la > > respuesta correcta es 117. WTF!? i.e.: no puedes confiar que MySQL te > > entregue respuestas correctas. > > bugs los tiene cualquiera no ?? y no son medios rebuscados esos ejemplos ?? De partida no son bugs, porque los de MySQL reconocen que estan ahi y no los reparan (en el manual dice por ahi que los numeros muy grandes son truncados y nuevamente, el usuario no tiene ningun mensaje de este hecho) No me parecen rebuscados en absoluto; si uno quiere datos consistentes, todos los datos tienen que ser consistentes, no solo los que son obviamente consistentes. Es que los gallos para ganar rendimiento sacan los chequeos de integridad que a mi juicio son basicos (y el de cualquiera que valore sus datos). > > (==> no puedes tener cluster _y_ transacciones _y_ rendimiento ... > > escoge solo una). > > ahi cada uno ve donde le aprieta el zapato, si se puede vivir con eso, cual > es > el problema ?? No se ... un motor de bases de datos que "inventa" cosas de esta manera como MySQL no me da ninguna confianza. Todo es bastante al lote. En PostgreSQL hay un esfuerzo constante para que esto no suceda, aunque a veces se pierda un poco de rendimiento. El tema de fondo es que lo importante es entregar respuestas correctas, aunque sea un poco mas lento. Si la respuesta es erronea, de que te sirve que te la entreguen muy rapido? Para eso mejor generas datos al azar, total igual estan malos. > respondiendo la pregunta original, yo diria que "depende". Yo diria que si los datos son importantes, no depende. Si es para hacer un sitio de articulos + comentarios y no importa que se pierdan algunos de vez en cuando, o que aparezcan datos brujos, entonces puede no importar ... pero si es el caso, mejor usa SQLite que es aun mas rapido. > En todo caso concuerdo que si aun no han escogido una db y el asunto a > desarrollar es grande (complejo), mejor tirarse por postgresql. No te quepa duda. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "Uno puede defenderse de los ataques; contra los elogios se esta indefenso" From [EMAIL PROTECTED] Thu Apr 29 09:24:31 2004 From: [EMAIL PROTECTED] (Horst von Brand) Date: Thu Apr 29 09:24:36 2004 Subject: Sistema de Archivos Ext3 In-Reply-To: Your message of "Wed, 28 Apr 2004 18:45:39 -0400." <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> "Alexander Gajardo" <[EMAIL PROTECTED]> dijo: > [1. text/html] La primera regla de la lista es correo en texto plano. Esto no me interera complicarme la vida para leerlo. La segunda regla es que voy a instalar un filtro de correos HTML en la lista. La tercera regla es que infractores reiterados (si, Uds saben quienes son) seran eliminados sin mas tramite. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From [EMAIL PROTECTED] Thu Apr 29 09:37:49 2004 From: [EMAIL PROTECTED] (Horst von Brand) Date: Thu Apr 29 09:37:53 2004 Subject: MySQL un DBMS? [Was: Re: otra duda] In-Reply-To: Your message of "Wed, 28 Apr 2004 18:48:40 -0400." <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> =?Windows-1252?Q?Esteban_Fern=E1ndez?= <[EMAIL PROTECTED]> dijo: > "Rodrigo Flores" <[EMAIL PROTECTED]> dijo: [...] > > calza Mysql dentro de las Bases de Datos relacionales, tal vez deberÃa > > preguntarme si es verdaderamente una BD. Es un administrador de archivos que maneja un subconjunto limitado de SQL. Solia tener mucho mejor rendimiento que las alternativas (a costa de no hacer "cosas complicadas" como transacciones o consultas complejas). Las alternativas se han hecho mas rapidas, y MySQL comenzo a agregar lo que le falta (como parches mas bien sucios), aunque le queda muchisimo camino por recorrer. En el proceso el rendimiento se fue de paseo. El consenso es que MySQL es alternativa si puedes garantizar para todo el futuro que jamas requeriras un verdadero RDBMS, y que estas dispuesto a pagar un costo severo en funcionalidad a cambio de una pequen~a ventaja en rendimiento para consultas muy simples, y que jamas requeriras mas que eso. Algunos analisis que he visto muestran que en uso real MySQL es _mucho_ mas lento que p.ej. Postgres (porque hay que hacer mucho a mano fuera de la base de datos, y el costo en rendimiento de eso es altisimo). Sin contar que el desarrollo se complica (y encarece), y que se corren riesgos serios de perdida de datos por falta de ACID. > Por supuesto que si, antes de haber preguntado aqui, hubiese sido bueno > ir a Google y verificar (solo un comentario), si defines en MySQL las > tablas de tipo InnoDB tienes transacciones funcionando impecablemente. Hay que hacer tonteras especiales para lograr (una parte de) la funcionalidad fundamental de un DBMS de verdad. Que te dice eso? PS: Es _tan_ dificil citar y responder como muestro aca? Se debe citar el mensaje original (indicando quien lo escribio), borrar lo irrelevante para la respuesta, y poner comentarios nuevos entre lo comentado? Es mucho trabajo tratar de poner titulos que sirvan de algo ("Duda", "Pregunta", "No tengo idea", ... nada aportan)? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From [EMAIL PROTECTED] Thu Apr 29 10:11:12 2004 From: [EMAIL PROTECTED] (Arturo Mardones) Date: Thu Apr 29 10:11:21 2004 Subject: Problemas con postfix Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAA6CQVXp/[EMAIL PROTECTED]> Hola, Tras haber instalado postfix tengo un problema de relay que no he podido solucionar... En mi log de maillog me aparece esto <[EMAIL PROTECTED]>, size=1697, nrcpt=1 (queue active) Y es que este correo de una compañía coreana esta usando mi servidor para hacer relay de su condenada propaganda... Ahora mi duda y por todo lo que he leído se supone que postfix es por defecto cerrado al relay ilegal, al parecer no es tan así pq estos señores igual mandan mail como condenados. Ahora mi servidor esta detrás de un firewall q le redirige los paquetes al puerto imap via reglas de iptables. Como puedo bloquear para q este correo no mande mas por mi servidor?? Les agradecere mucho cualquier idea o dato!! Gracias, Arturo Mardones F. Core Technologies Ltda. http://www.coretech.cl Bustamante 16, Of 3A, Providencia Santiago, Chile Fono: 56-2-2698822
