MySql: ¿Una base de datos menor de edad?

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

[roman]

Empezado por haron

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

Mi versión es la 3.23.52 y funciona correctamente siempre.

// Saludos

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

[guillotmarc]

Hola.

Empezado por kinobi

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

Cierto, uno de los proyectos Open Source, que sigo con más interés es el Mono, y aunque están en la versión 0.31, es perfectamente funcional en muchos apartados. Aunque el nivel de estabilidad de los distintos modulos funcionales del proyecto, varia bastante. Tienen modulos muy robustos (como el compilador C#), y modulos recien implementados que necesitan mucha depuración (como el ASP.Net).

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

[guillotmarc]

Hola.

Empezado por marto

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

Pero eso indica que el lenguaje de consultas es limitado, te fuerza a definirte objetos adicionales en la base de datos, para obtener esos resultados (ya sean vistas, tablas temporales o heap tables, que en el fondo hace lo mismo pero de forma más eficiente al residir totalmente en memoria).

¿ Que ocurre si no eres el Administrador de la Base de Datos ?. Si solo tienes derechos a realizar consultas, pero sin poder crear objetos, vas a tener que complicarte la vida haciendo calculos en el cliente.

Empezado por marto

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

Gracias, no conocía la traducción al castellano de los correlated subquerys. Te recomiendo que los utilizes, són muy utiles, te permiten sacar resultados complejos en la misma consulta.

Empezado por marto

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.

Pues en MySQL tampoco tienes esta opción, ya que las versiones estables no soportan procedimientos almacenados. Y está por ver si la versión 5 va a permitir utilizar un procedimiento almacenado como una función en una consulta, ya que tengo mis dudas de que esto forme parte del estándar SQL (SQL Server 7, por ejplo., no admitía esta posiblidad).

Naturalmente muchas veces habrá alguna forma de sortear el problema. Por ejemplo se me ocurre crear dos vistas como :

create view NumVentas as 
select Codigo, count(*) as nVentas
from Ventas inner join Clientes on Clientes.Codigo = Ventas.Codigo
group by Codigo
 
create view NumPedidos as 
select Codigo, count(*) as nPedidos
from Pedidos inner join Clientes on Clientes.Codigo = Pedidos.Codigo
group by Codigo

Entonces ya puedes realizar la consulta :

select Codigo, nVentas, nPedidos
from Clientes
	 left outer join NumVentas on Clientes.Codigo = NumVentas.Codigo
	 left outer join NumPedidos on Clientes.Codigo = NumPedidos.Codigo

El resultado es el mismo (aunque no siempre habrá esta posiblidad), pero no es comparable la elegancia y sencillez de la solución con subconsultas, que el tener que utilizar vistas o procedimientos almacenados. Además de el hecho ya comentado de que la persona que necesita la consulta, quizá no tenga la posiblidad de crear objetos en la base de datos.

Empezado por marto

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.

No estoy de acuerdo en absoluto. Si tienes los indices adecuados, se van a utilizar los mismos índices en la correlated subquery y en el procedimiento almacenado, resultando en el mismo rendimiento. O quizá ligeramente mejor en la subconsulta, puesto que no tiene la sobrecarga del paso de parámetros y recogida del resultado. (aunque esto último es solo una estimación mía).

Saludos.