MySql: ¿Una base de datos menor de edad?

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

[guillotmarc]

Hola.

Empezado por 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.

Bien, soporta transacciones y integridad referencial, pero nada más de lo que has dicho.

¿ lenguaje de consultas completo ? Ni tan solo permite subconsultas. (claro se puede decir que MySQL 4.1 va a soportarlas, pero ya hablamos de una versión en desarrollo, una alfa).

¿ mayoria de las posibilidades que ofrecen las bases de datos relacionales ?. Que una base de datos relacional como Access si, pero que un Servidor SQL no. No está al nivel de Interbase, Oracle, ... No ofrece triggers, procedimientos almacenados, cursores, ... Otra vez se puede decir que aparecerán en la versión 5, pero vuelve a ser una versión en desarrollo, de la que solo existen versiones alfa.

¿ Cuando van a salir las versiones 4.1 y 5 ?. Cuando salgan MySQL va a ser un Servidor SQL, pero ahora mismo no se pueden utilizar, solo para hacer pruebas, pero no en un sistema en producción. El tema del debate es MySql: ¿Una base de datos menor de edad? : para mi si, aún es immadura. La versión estable actual funciona muy bien para aplicaciones Web, que tienen unas necesidades muy limitadas, pero se queda corta para aplicaciones cliente/servidor.

Saludos.

[kinobi]

Hola,

Empezado por guillotmarc

El tema del debate es MySql: ¿Una base de datos menor de edad? : para mi si, aún es immadura. La versión estable actual funciona muy bien para aplicaciones Web, que tienen unas necesidades muy limitadas, pero se queda corta para aplicaciones cliente/servidor.

si lo quieres ver así: la versiones de producción actuales son inmaduras (desde la referencia de otros gestores), de acuerdo ... y yo añado: las actuales versiones en desarrollo 4.1 y 5 (pueden llamarlas alpha, beta, gamma, ... como otros las llaman Release Candidate 1, 2, 3, ... y otros a, b, c, ...) no lo son (EMHO).

Saludos.

[guillotmarc]

Hola.

Empezado por kinobi

si lo quieres ver así: la versiones de producción actuales son inmaduras (desde la referencia de otros gestores), de acuerdo ... y yo añado: las actuales versiones en desarrollo 4.1 y 5 (pueden llamarlas alpha, beta, gamma, ... como otros las llaman Release Candidate 1, 2, 3, ... y otros a, b, c, ...) no lo son (EMHO).

Estoy casi de acuerdo, aunque yo diria que la versión actual es limitada en funcionalidades, y la versión en desarrollo (la 5) ya será completa. Pero incluso cuando llegue esta versión voy a pensar que MySQL es immaduro. La madurez se la va a ganar con los años.

No me parece comparable el Alfa de MySQL con los Release Candidate. Pongamos como ejplo. Firebird 1.5 que pasó un ciclo muy largo de Release Candidates, antes de entrar en el ciclo de RC's estuvo más de un año en desarrollo, con versiones Alfa (toda la conversión de código de C a C++), http://cvs.sourceforge.net/viewcvs.p...se&view=markup. En concreto hubo 5 Alfas y 4 Betas.

Aunque dependiendo de los gestores del proyecto, se mantiene más tiempo en una etapa que en otras (el mismo Firebird 1.5 hubiera sido más razonable que las primeras RC hubieran salido como betas), esto no quita de que MySQL no ha entrado aún en fase Beta. La documentación de MySQL indica que hay apartados que aún se están programando (aunque los procedimientos almacenados ya estén implementados), por lo que es de esperar que hasta que no terminen de programar, no van a empezar con la fase Beta y la detección y corrección de bugs. No hay que olvidar que tienen un trabajo enorme para fusionar SapDB y MySQL.

Saludos.

[haron]

probad esto:

mysql> create table t(
    -> id int not null auto_increment primary key,
    -> nom varchar(50) not null);
Query OK, 0 rows affected (0.00 sec)
 
mysql> insert into t(nom) values('hola');
Query OK, 1 row affected (0.00 sec)
 
mysql> select * from t where id is null;
+----+------+
| id | nom  |
+----+------+
|  1 | hola |
+----+------+
1 row in set (0.00 sec)

ouhhhoou!!! ohuuhuoou!!

mola.

mi version de mysql es la 3.23.54
solo funciona la primera vez. cuando volvemos a lanzar el 'select' devuelve un resultado correcto.

[kinobi]

Hola,

Empezado por guillotmarc

No me parece comparable el Alfa de MySQL con los Release Candidate. Pongamos como ejplo. Firebird 1.5 que pasó un ciclo muy largo de Release Candidates, antes de entrar en el ciclo de RC's estuvo más de un año en desarrollo, con versiones Alfa (toda la conversión de código de C a C++), http://cvs.sourceforge.net/viewcvs.p...se&view=markup. En concreto hubo 5 Alfas y 4 Betas.

De todas formas, el asunto del nombre de las versiones a veces no es significativo, espacialmente en desarrollos open source (o con origen open source), como es el caso de MySQL. Una versión numerada como 0.1 en este tipo de desarrollos suele ser perfectamente funcional, cosa impensable en desarrollos cerrados (o de origen cerrado).

Saludos.

[marto]

Empezado por guillotmarc

¿ lenguaje de consultas completo ? Ni tan solo permite subconsultas.

Eso no es enteramente cierto. Es verdad que no soporta subconsultas "estandard", pero mediante el mecanismo de heap tables permite conseguir los mismos resultados de manera mucho más rápida. Es cierto que esta técnica no permite consultas sincronizadas, pero yo aun no me he encontrado con la necesidad de hacer una nunca en el "mundo real"

[guillotmarc]

Hola.

Interesante el concepto de Heap Tables, no lo conocía. Pero si no me equivoco no són más que tablas en memória. Muy rápidas para hacer consultas, pero no proporcionan ninguna capacidad adicional para realizar consultas. No permiten realizar ninguna consulta que no se pudiese realizar sobre tablas normales y/o vistas. ¿ Me equivoco ?.

Me parece curioso que no necesites subconsultas, puesto que yo las utilizo muy a menudo. Algunas veces (solo algunas) se pueden sustituir por un Join y opcionalmente una agrupación, pero la sintaxis con subconsulta suele ser mucho más elegante y fácil de entender y mantener.

Veamos un ejemplo muy simple : ¿ Como harías sin subconsultas, un listado de clientes, con su total de pedidos y ventas ?

select cliente, 
(select count(*) from pedidos where pedidos.codigo = cliente.codigo) as pedidos,
(select count(*) from ventas where ventas.codigo = cliente.codigo) as ventas
from clientes

Saludos.

[marto]

Empezado por guillotmarc

Interesante el concepto de Heap Tables, no lo conocía. Pero si no me equivoco no són más que tablas en memória. Muy rápidas para hacer consultas, pero no proporcionan ninguna capacidad adicional para realizar consultas.

Pues si no me equivoco, gracias al dialecto de MySql, puedes crear heap con los datos que necesitas en tu subconsulta y usarla en la query principal. No suple a todas las subconsultas pero sí a alguna.
Lo que quiereo decir con esto es que, si bien es cierto que le faltan algunas características comunes a otros servidores, la peculiaridad de MySql hace que te perimita hacer las mismas cosas "de otras maneras".

Empezado por guillotmarc

Me parece curioso que no necesites subconsultas,...

No quería decir que no necesitase subconsultas sino subconsultas sincronizadas

Empezado por guillotmarc

Veamos un ejemplo muy simple : ¿ Como harías sin subconsultas, un listado de clientes, con su total de pedidos y ventas ?

select cliente, 
(select count(*) from pedidos where pedidos.codigo = cliente.codigo) as pedidos,
(select count(*) from ventas where ventas.codigo = cliente.codigo) as ventas
from clientes

Pues no sé cómo se haría en MySql (que no dudo que se puede, pero lo tengo algo olvidado), pero, de todas maneras, ese tipo de consultas las acostumbro a hacer con procedimientos, mucho más eficientes, por lo menos en Oracle que es con lo que trabajo habitualmente.

  
  select cliente, pedidos_cliente(cliente) as pedidos, ventas_cliente(cliente) as ventas
  from clientes