MySql: ¿Una base de datos menor de edad?

[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.

[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.

[kinobi]

Hola,

Empezado por jachguate

Creo que despues de esto realmente dejaré de considerar a mySQL como un candidato serio para aplicaciones "reales".

Creo que es excesivo el no considerar a MySQL un candidato serio para aplicaciones "reales". Desde luego no cuestiono que no se adapate a tus necesidades, pero de ahí a que no sea una opción seria, hablando en términos genéricos, va un mundo. Especialmente cuando (aparentemente) tu opinión se basa en una lista de aspectos discutibles de este servidor que, aunque ilustrativa de algunos aspectos a mejorar, no creo que sea muy diferente (en cuanto a número e importancia) de otros gestores.

Sólo por poner un ejemplo de hace unos minutos: aunque no he encontrado una lista tan exhaustiva y ordenada como la de Marc, sí que he encontrado más de un enlace con aspectos controvertidos (algunos de ellos bugs resueltos y no resueltos) de un gestor muy popular: MS-SQL Server (en varias de sus versiones).

En fin, que si es por aspectos discutibles, seguro que ni tu viejo y querido B'trieve se salva de ellos.

Saludos.

[jachguate]

Empezado por kinobi

es excesivo el no considerar a MySQL un candidato serio para aplicaciones "reales".

Bueno... si es excesivo, pero en lo personal, al menos en el futuro cercano, no pienso hacerlo, para aplicaciones "reales" de escritorio, aunque sigue siendo mi primera opción para aplicaciones "reales" sobre webservers

Empezado por kinobi

de ahí a que no sea una opción seria, hablando en términos genéricos, va un mundo.

Creo no haber dicho que no sea una opción seria... y si me di a entender asi, por supuesto que no supe explicarme. sorry.

Empezado por kinobi

cuando (aparentemente) tu opinión se basa en una lista de aspectos discutibles de este servidor

Bueno, es que yo ya tenía una opinión. Debido a este debate, estaba pensando re-considerar mi postura, pero al final, solo la he reafirmado.

Empezado por kinobi

no creo que sea muy diferente (en cuanto a número e importancia) de otros gestores.

Lo entiendo... en todos lados se cuecen habas.

Empezado por kinobi

he encontrado más de un enlace con aspectos controvertidos (algunos de ellos bugs resueltos y no resueltos) de un gestor muy popular: MS-SQL Server (en varias de sus versiones).

Bueno... no quiero levantar polémica, pero creo que sobre este debieran haber por lo menos un par de toneladas de links...

Empezado por kinobi

que si es por aspectos discutibles, seguro que ni tu viejo y querido B'trieve se salva de ellos.

Porque crees que se ha quedado relegado a un "viejo y querido"??? claro que no está al nivel del actual y amadisimo oracle...

Saludos.

[kinobi]

Hola,

Empezado por jachguate

Bueno... si es excesivo, pero en lo personal, al menos en el futuro cercano, no pienso hacerlo, para aplicaciones "reales" de escritorio,

Como dije antes, no pongo en duda que no se adapte a tus necesidades y no puedas considerarlo como una opción, pero otros muchos, muchísimos, sí lo hacen y no les va mal.

Empezado por jachguate

Creo no haber dicho que no sea una opción seria... y si me di a entender asi, por supuesto que no supe explicarme. sorry.

Bueno, tomo "opción seria" y "candidato serio" (esto sí que creo que lo dijiste) como sinónimos.

Saludos.