MySql: ¿Una base de datos menor de edad?

[marto]

Wop!

A raiz de un hilo planteado en el foro de IB en el que un usario planteaba dudas al migrar a Firebird y que hacía referencia a MySql como una base de datos para "proyectos pequeños", ha renacido en mí una duda que he tenido siempre: ¿Por qué todo el mundo se mete con MySql?

Excepto aquellos desarrolladores que han tenido larga experiencia con ella, la mayoría opinan que es un sistema rápido, pero que le falta robustez, características para poderse comparar con productos como Oracle, Interbase o SQLServer.

Pues a mi me parece que no!

¿Por que la nasa migró parte de sus sistemas a MySql cuando los tenía desarrollados?¿Porque no es una BD robusta?... a mi me parece que no!

Se ha argumentado que no tiene soporte para transacciones... a mi me parece que sí!

Tambien se ha dicho que no soporta integridad referencial... a mi me parece que tambien

La diferencia entre MySql y otros servidores es que en mysql, si prefieres prescindir de una característica para que la cosa chute más rápida, lo haces, sin más.

Bueno, el debate está abierto... hagan juego!

[kinobi]

Hola,

el problema es que las características que citas han sido añadidas en sucesivas versiones y, a fuerza de inercia, la gente sigue teniendo prejuicios contra MySQL.

Saludos.

[marto]

Hablamos de los "añadidos" de SQLServer? Por no nombrar las demas, todas han ido evolucionando!!!!!

[kinobi]

Empezado por marto

Hablamos de los "añadidos" de SQLServer? Por no nombrar las demas, todas han ido evolucionando!!!!!

Claro, claro, a eso me refiero. Lo que quiero decir es que a pesar de que ha evolucionado, y sigue haciéndolo, MySQL sigue siendo considerado erróneamente por muchos como un gestor de bases de datos menor, debido a que toman como referencia las características que tenía hace años y no las que tiene ahora.

Saludos.

[*Emilio*]

Lamentablemente ya no es la base de datos gratuita que era, de ahí que PHP esté ya tomando alternativas como SQLite y similares.

Por las pruebas que hemos hecho, MySQL es la mas rápida con diferencia cuando tiene pocos registros, a la que le metes una tabla con 100 campos y un par de millones de registros, se le caen los pantalones.

[marto]

Empezado por Emilio

Lamentablemente ya no es la base de datos gratuita que era, de ahí que PHP esté ya tomando alternativas como SQLite y similares.

Eso es una verdad a medias! MySql digue distribuyendose bajo licencia GPL, lo que sucede es que si lo que tú vas a programar no quieres que esté bajo esa licencia, entonces tienes que comprar el producto antes.

Empezado por Emilio

Por las pruebas que hemos hecho, MySQL es la mas rápida con diferencia cuando tiene pocos registros, a la que le metes una tabla con 100 campos y un par de millones de registros, se le caen los pantalones.

Pues no sé como habrás hecho esas pruebas, pero no son los datos que yo tenía. He estado buscando (sin suerte ) una compartiva entre MySql, Oracle y SQLServer donde MySql quedaba casi a la par que Oracle y muy por encima que elde M$.

[roman]

Algo que me gustaría agregar.

Hace no mucho vi aquí un hilo donde se preguntaba como realizar un sistema en Interbase que accediera a varias bases de datos. Yo no conozco Interbase pero me sorprendió sobremanera ver que no tiene una capacidad que MySql tiene casi desde sus inicios (sino es que desde el comienzo mismo) que es la de poder realizar consultas involucrando varias bases de datos (eso sí, en el mismo servidor).

Un saludo

[[Al González]]

¡Hola a todos!

Hace poco más de un año, cuando investigaba acerca de MySQL, me encontré con varios documentos que comentaban la carencia de transacciones en ese manejador de base de datos.

Creo que es una cuestión de sicología y mercadotecnia.

Imaginemos el escenario:

— ¡Oh! ¿Que será eso de "MySQL"? Suena como a una combinación de Mis Documentos y SQL Server. Tal vez sea uno de esos productos impopulares y torpes de Microsoft, como la libreta de direcciones o el asistente de Office. O tal vez es se trata de una de sus nuevas tecnologías de lentos y pesados DLLs, quizá su nuevo OLE, Toro, OLE. O quizás su versión ultra ampliada del lenguage SQL. ¿Querrá imponerlo al mundo? Seguramente estará lleno de Update Facking Patchs.

— ¡Oh! Parece que no es eso, de hecho está ligado con PHP. Ah, ya veo, aquí dice que se usa mucho en PHP porque es una base de datos ligera, sencilla y suficiente para la mayoría de las páginas web que todo lo que hacen es mostrar unos cuantos registros de algunas tablas. Inclusive, aquí dice que no maneja transacciones porque casi no se necesitan en páginas Web. Ojalá de todas formas PHP pueda trabajar con otras bases de datos mejorcitas.

Lamentablemente existen muchos productos buenos como MySQL o extraordinarios como Delphi, cuyo rechazo se basa en los prejuicios sicológicos que en muchas personas causan palabras y frases como "My", "SQL Server", "Pascal", "fuertemente tipificado", "lenguaje de mediano nivel", etc.

A veces hasta miedo me da decir que cierta función es sobrecargada (Overload). No valla a ser que se crea que es una función pesadota, lenta y con 53 parámetros por valor y 114 por variable (como las de Microsoft )

Recuerdo las palabras de Rodrigo Baca, mi exjefe de 1997:

— Vamos a optar por Visual Basic porque parece ser un lenguaje popular y fácil de usar.

La mercadotecnia es una camión sin frenos viajando cuesta abajo por una larga y vacía calle. Podemos esperar a que se estrelle (dentro de varias décadas) o ahorrar tiempo, adelantarnos, subir la pesada pero honorable cuesta y colocar en la cima la bandera de MySQL, Delphi, Oracle, Interfaz GH , y otros productos de calidad.

Atentamente,

Al González .

[jachguate]

Pues yo también tengo mis reservas con mySQL. Que haya resultado "casi" igual a Oracle en algunas pruebas.. lo considero "casi" imposible... aunque habria que ver los parámetros y por donde van tirando las balas...

He leido un documento de hace unos 3 o 4 años, donde ciertamente mySQL resulta la mejor base de datos para la gran mayoría de aplicaciones web, cosa que no discuto en el presente... pero en ese mismo test, interbase, para sorpresa de muchos (incluido yo) resultó ser la mas escalable (número de usuarios y número de registros almacenados).

En cuanto a las transacciones... según yo seguia sin tenerlas, o es que las tiene a partir de las últimas versiones. No se que tan desarrollado esté su lenguaje de triggers y stored procedures... ni cómo este su rendimiento (optimización) que por cierto es donde peor puede calificarse a Interbase (no he tenido tiempo ni oportunidad de evaluar a fb).

Lo cierto, es que, al menos yo, tengo relegado a mySQL para proyectos web, de donde no pienso moverlo en un furuto cercano... pero ni me he atrevido a probarlo para un proyecto de escritorio, multiusuario, etc, etc.

Habrá que hacer unas pruebas de nuevo... de hecho, yo tengo instalado mySQL, Oracle e Interbase en mi servidor... si alguien se prepara unas pruebas, con carga pequeña, mediana y grande, podemos llegar a nuestras propias conclusiones. Me envian los scripts... los aplicativos, y yo me encargo de correr los tests y publicar los resultados.

Hasta luego.

[abel]

Hola a tod@s:

Hace unos meses tuvimos que decidir, en mi empresa, qué base de datos usar para que los clientes accedieran por internet a una serie de información personalizada, sólo consultas, no pueden dar altas ni hacer modificaciones.

Hicimos pruebas con MySql 4 y con Firebird 1. Cuando había unos pocos miles de registros, MySql respondía muy bien, aunque Firebird no se quedaba atrás, sin embargo, cuando se pasó los 50.000 registros, normalmente Firebird respondía antes a las consultas y lo qué sí ocurría siempre es que cuando había más de 30 ó 40 usuarios conectados, siempre respondía mucho antes firebird, con gran diferencia.

Quizás a todos no les vaya igual, pero esa fue nuestra experiencia y hasta ahora nos va estupendamente con unos 80 usuarios conectados todo el tiempo, de media, y varios millones de registros.

Hicimos unas pequeñas pruebas con Oracle y nos resultó algo lenta en comparación y teniendo en cuenta su coste económico decidimos no usarla.

Hemos visto que MySql ha hecho grandes avances e incluso ahora, si tuviéramos que volver a decidir, también haríamos pruebas con MaxDb, que parece muy interesante.

En fin, que no hay nada definitivo, todo depende del proyecto a realizar, de los gustos, del precio e incluso de las manías personales.

Saludos para tod@s.

[guillotmarc]

Hola.

De acuerdo, MySQL ya tiene por fin Integridad referencial y Transacciones (solo si utilizas el formato de archivos MaxDB), pero aún así está muy lejos de tener las características básicas que ofrecen los servidores SQL. Por no tener, a estas alturas aún sigue sin aceptar subconsultas, que van a aparecer en la nueva versión MySQL 4.1 (actualmente en estado Alpha), por no hablar de Procedimientos almacenados, Triggers, Cursores, ... (están en el planning para la versión 5).

Quizá dentro de unos años si que llegará a ser un Servidor SQL aceptable, pero ahora mismo para mi, le viene como anillo al dedo la denominación de nuevo dBase, puesto que simplemente es un archivo de datos, sin posiblidades cliente / servidor.

Saludos.

[kinobi]

Hola,

algunos comentarios:

Empezado por guillotmarc

De acuerdo, MySQL ya tiene por fin Integridad referencial y Transacciones (solo si utilizas el formato de archivos MaxDB),

en realidad la posibilidad de uso de control transaccional está en la división del servidor de datos y el gestor de almacenamiento. Tal como yo lo entiendo son dos procesos diferentes dentro de la arquitectura MySQL. Si deseas control transaccional debes usar un motor de almacenamiento como los descritos en la web de MySQL: InnoDB o Berkeley database (BDB) storage engine. En caso de no querer transacciones, puedes usar el propio de MySQL (seguramente más veloz).

Empezado por guillotmarc

por no hablar de Procedimientos almacenados, Triggers, Cursores, ... (están en el planning para la versión 5).

Por lo que pone en la web, no están en planning, están ya en desarrollo. Además de estar disponible ya para descarga la versión 5 (en la rama de desarrollo). Recuerdo haber leído hace tiempo (medio año o más) que los procedimientos almacenados ya estaban operativos en esta versión.

Empezado por guillotmarc

Quizá dentro de unos años si que llegará a ser un Servidor SQL aceptable, pero ahora mismo para mi, le viene como anillo al dedo la denominación de nuevo dBase, puesto que simplemente es un archivo de datos, sin posiblidades cliente / servidor.

Esto no lo entiendo. ¿Por qué un servidor MySQL no tiene posibilidades cliente/servidor y un InterBase (o MS-SQL server, u Oracle, ...) sí?

Saludos.

[guillotmarc]

Hola.

Empezado por kinobi

en realidad la posibilidad de uso de control transaccional está en la división del servidor de datos y el gestor de almacenamiento. Tal como yo lo entiendo son dos procesos diferentes dentro de la arquitectura MySQL. Si deseas control transaccional debes usar un motor de almacenamiento como los descritos en la web de MySQL: InnoDB o Berkeley database (BDB) storage engine. En caso de no querer transacciones, puedes usar el propio de MySQL (seguramente más veloz).

¿ No es lo mismo que he dicho yo ?. Si quieres utilizar transacciones entonces debes usar MaxDb (o por lo que comentas el BDB, que no conocía), en cambio si no las necesitas puedes usar el tradicional InnoDb, el cual no sacrifica rendimiento por esas opciones. Por eso aún lo mantienen, el mayor mercado de MySQL aún se encuentra en las aplicaciones Web, y en esas aplicaciones no suelen utilizar transacciones.

Empezado por kinobi

Por lo que pone en la web, no están en planning, están ya en desarrollo. Además de estar disponible ya para descarga la versión 5 (en la rama de desarrollo). Recuerdo haber leído hace tiempo (medio año o más) que los procedimientos almacenados ya estaban operativos en esta versión.

Exacto, están en la versión en desarrollo, y en el planning oficial de esa versión http://www.mysql.com/doc/en/TODO_MySQL_5.0.html. Algunas características del planning ya se encuentran disponibles en versiones Alfa, y otras no. En todo caso estarás de acuerdo conmigo en que no sería nada aconsejable utilizarlo en un sistema en producción. Si se encuentran en fase Alfa es porqué aún se están depurando y ultimando detalles. (Ni tan solo está en fase Beta, en cualquier momento pueden cambiar completamente el comportamiento de una función, o hacerla desaparecer).

Empezado por kinobi

Esto no lo entiendo. ¿Por qué un servidor MySQL no tiene posibilidades cliente/servidor y un InterBase (o MS-SQL server, u Oracle, ...) sí?

¿ Que entiendes por Cliente/Servidor ?. Puesto que yo lo entiendo en que parte de la carga del proceso a realizar se puede trasladar al Servidor. Pero para eso tienes que programarlo en el servidor, usando Triggers, Procedimientos Almacenados, ... Pero estos aún no están disponibles en MySQL, ni tan solo en fase Beta, solo en versiones Alfa que aún se encuentran en desarrollo.

Por cierto, si os quereis divertir un rato, viendo la cantidad de comportamiento no estándar de MySQL, no dejeis de visitar este documento :

http://sql-info.de/mysql/gotchas.html

Saludos.

[kinobi]

Hola,

Empezado por guillotmarc

¿ No es lo mismo que he dicho yo ?.

Yo entiendo que no ...

Empezado por guillotmarc

Si quieres utilizar transacciones entonces debes usar MaxDb (o por lo que comentas el BDB, que no conocía), en cambio si no las necesitas puedes usar el tradicional InnoDb,

Tal vez lo haya entendido yo mal, pero la idea que tengo es esta:

* MaxDB es la versión de MySQL (como empresa, no como producto) de la versión Open Source de SAP-DB.

* InnoDB y Berkeley database (BDB) storage engine son los dos motores de almacenamiento que proporcionan control transaccional a MySQL.

* MySQL-ISAM es el motor de almacenamiento estándar (y que no da control transaccional) a MySQL.

Empezado por guillotmarc

Exacto, están en la versión en desarrollo, y en el planning oficial de esa versión

Pasé por el alto el artículo "el" en: "el plannig"; de ahí que entendiera que te referías a que esas características se estaba estudiando si incluirlas o no.

Empezado por guillotmarc

¿ Que entiendes por Cliente/Servidor ?.

Un sistema donde intervienen dos o más procesos comunicándose entre sí, actuando uno (o más) de ellos como prestador de una serie de servicios (almacenamiento, proceso, ...)

Proceso servidor <-> Procesos clientes

Empezado por guillotmarc

Puesto que yo lo entiendo en que parte de la carga del proceso a realizar se puede trasladar al Servidor.

Pero eso, en todo caso, es un asunto del reparto de cargas entre el servidor y los clientes, no algo que describa el sistema como cliente/servidor o no.

Saludos.

[guillotmarc]

Hola.

Empezado por kinobi

Tal vez lo haya entendido yo mal, pero la idea que tengo es esta:

* MaxDB es la versión de MySQL (como empresa, no como producto) de la versión Open Source de SAP-DB.

* InnoDB y Berkeley database (BDB) storage engine son los dos motores de almacenamiento que proporcionan control transaccional a MySQL.

* MySQL-ISAM es el motor de almacenamiento estándar (y que no da control transaccional) a MySQL.

Seguro que tienes razón, y estaba equivocado yo con los nombres. MySQL solo lo he probado una vez, hace dos años, y al verlo tan limitado lo abandoné enseguida.

Lo único que quería resaltar es que aún mantiene un modo para trabajar sin transacciones, porqué en el modo con transacciones han tenido que sacrificar rendimiento, que es la principal virtud que promocionan.

Empezado por kinobi

Un sistema donde intervienen dos o más procesos comunicándose entre sí, actuando uno (o más) de ellos como prestador de una serie de servicios (almacenamiento, proceso, ...)

Yo más bien pondría un Y. Almacenamiento y Proceso.

En una aplicación Clipper de hace 10 años, también se podía ubicar la base de datos sobre un Servidor de Red que proporcionaba el almacenamiento. Pero no por ello se llamaban aplicaciones Cliente/Servidor.

MySQL no proporciona mucho más que eso : Almacenamiento. ¿ Como se puede procesar en el Servidor sin Triggers ni SP's ?, cualquier cosa que se quiera hacer, hay que bajar los datos al cliente, procesarlos y enviarlos de vuelta al Servidor.

No encuentro una buena definición del Paradigma de las aplicaciones Cliente/Servidor, así que acepto que una aplicación MySQL pueda entrar en esa definición para otra persona. Pero para mi le falta mucho para serlo, en su estado actual lo considero poco más que un dBase optimizado.

No digo que sea un mal producto, lo poco que hace, lo hace rápido (puse bien y rápido, pero he quitado el bien, he recordado como me partí de risa al leer la lista de gotchas de MySQL). Pero el tema del debate es si es una base de datos menor de edad, y en ese punto no resiste la menor comparativa con otras Bases de Datos como Oracle, PostgreSQL, SQL Server, DB2, Firebird, ... A su versión estable actual le faltan tantas, tantas, tantas funciones, que me niego en redondo a llamarla incluso un Servidor SQL. Marto, por favor si encuentras la comparativa con Oracle y SQL Server, no dejes de publicarla aquí (o directamente en el Foro de Humor ), me gustaría pasar un buen rato al leerla .

Veremos con el tiempo como evoluciona. Pero su última versión estable, en mi opinión, es efectivamente un producto altamente limitado y immaduro.

Saludos.

[kinobi]

Hola,

Empezado por guillotmarc

Lo único que quería resaltar es que aún mantiene un modo para trabajar sin transacciones, porqué en el modo con transacciones han tenido que sacrificar rendimiento, que es la principal virtud que promocionan.

Sí, es cierto. Aunque estoy convencido que si a otros servidores SQL, que ofrezcan control transaccional, se les pudiese "desactivar" esa característica, seguro que ofrecerían también un mejor rendimiento.

Empezado por guillotmarc

Yo más bien pondría un Y. Almacenamiento y Proceso.

Bueno, yo estaba dando una definición genérica, no sólo para servidores de datos. Desde ese punto de vista, MySQL sí permite la creación de sistemas cliente/servidor. Por otro lado, es fácil encontrar autores que no comparten la opinión de la bondad de las arquitecturas de "cliente ligero", llevando toda la carga del proceso al servidor, especialmente con el uso de procedimientos almacenados y triggers, debido a que el lenguaje que soportan estos suele ser incompatible entre productos de distintos fabricantes. Vamos, que no existe una opinión unánime al respecto.

Empezado por guillotmarc

MySQL no proporciona mucho más que eso : Almacenamiento. ¿ Como se puede procesar en el Servidor sin Triggers ni SP's ?, cualquier cosa que se quiera hacer, hay que bajar los datos al cliente, procesarlos y enviarlos de vuelta al Servidor.

Como hemos visto, en la próxima versión 5, eso ya está previsto.

Empezado por guillotmarc

No digo que sea un mal producto, lo poco que hace, lo hace rápido (puse bien y rápido, pero he quitado el bien, he recordado como me partí de risa al leer la lista de gotchas de MySQL).

Sólo la he visto por encima, aunque volveré a ella para leerla con calma, pero también se pueden montar listas de aspectos discutibles con otros gestores de datos.

Empezado por guillotmarc

Pero el tema del debate es si es una base de datos menor de edad, y en ese punto no resiste la menor comparativa con otras Bases de Datos como Oracle, PostgreSQL, SQL Server, DB2, Firebird, ...

Por lo que he argumentado anteriormente, no comparto tu opinión.

Saludos.

[haron]

se que mysql es actualmente una base de datos que soporta transacciones, integridad referencial, un lenguaje de consultas completo y en definitiva, la mayoria de las posibilidades que ofrecen las bases de datos relacionales como Interbase, Oracle e incluso Access.

pero por desgracia, cuando contratas un hosting en una pagina web con mysql incorporado te das cuenta que la mayoria de las empresas ofrecen un mysql limitado: sin transacciones, sin integridad referencial y con un lenguaje de consultas muy limitado.

porque? en principio creo que es para no cargar al servidor, ya que tiene que atender multiples peticiones a bajo coste.

osea, que por muy sotisficado que sea actualmente mysql, los servidores web siempre van a ofertar una version reducida.

a no ser que conozcais una empresa de hosting que ofrezca un servicio mysql completo (transacciones, etc.. etc..)

si la conoceis decidmelo.

[kinobi]

Empezado por haron

osea, que por muy sotisficado que sea actualmente mysql, los servidores web siempre van a ofertar una version reducida.

pero eso es, en todo caso, un problema del proveedor del hosting, no de MySQL.

Saludos.

[haron]

realmente esa es la filosofia del producto, ofrecer un servicio mas o menos decente a bajo coste.

por eso uno se asombra al ver como una base de datos que surgio con tan pocas prestaciones tuvo tanto exito. hay que pensar en terminos economicos. para la mayoria de las empresas era la mejor opcion.

otra cosa es que hayan decidido crear un producto maduro y que pueda competir con otras bases de datos.

de todas formas mysql es la base de datos que ofrecen muchas compañias y ellas van a seguir siendo fieles a la filosofia original.

[jachguate]

Empezado por guillotmarc

Por cierto, si os quereis divertir un rato, viendo la cantidad de comportamiento no estándar de MySQL, no dejeis de visitar este documento :

http://sql-info.de/mysql/gotchas.html

Saludos.

Divertir???

No ha sido muy divertido para mi, pues me ha preocupado sobremanera algunos asuntos que eran de mi total desconocimiento... lo admito, a investigar sobre mySQL no he podido dedicarle mas de unas pocas horas... y lo he tomado como "otro" servidor SQL, simplemente sin transacciones y sin integridad.

Pero el tratamiento que da a los NULL me parece realmente triste, por no hablar de las divisiones por cero. Todos, problemas que estoy acostumbrado a delegar al servidor y esperar que este responda si algo va mal... no que simplemente "procese a su gusto" estas condiciones. El comportamiento del test "bounds_text" me parece que es una muestra de lo loejos que han querido llegar, manejando por si mismos condiciones de error que debieran atañar solamente a quien desarrolla sobre la base de datos, y no a la base de datos en si. Gracias, amigo marc, por la información y marto por haber iniciado este debate. Creo que despues de esto realmente dejaré de considerar a mySQL como un candidato serio para aplicaciones "reales". Es mas, tengo un proyecto en puerta, donde tengo pensado usar firebird en la aplicación "real", y via proceso, subir algunas cosas que deben estar disponibles solo para consulta en la web, a mySQL. Asi mantendré el asunto -que sinceramente ya estaba pensando re-evaluar mi decisión original- ya que pocas veces sacrificaría características por el simple desempeño. De todas formas, si esa fuera mi filosofía, no creo ni siquiera que utilizara mySQL. Me quedo con mi viejo y querido B'trieve, que hace palidecer a Firebird, y quizas hasta la mayoría de instalaciones de Oracle (no dudo que también a mySQL) en lo que a desempeño se refiere y ese si que tenía transacciones... (operaciones a bajo nivel: begin_tran, end_tran y cancel_tran), sin siquiera atreverse a llamarse una base de datos .

Hasta luego.