MySql: ¿Una base de datos menor de edad?

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

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

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

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

[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

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

[guillotmarc]

Por cierto, no tengo ninguna duda de que MySQL va a ser una opción a tener en cuenta a largo plazo. Algunos gigantes de la industria se empiezan a volcar en él (hace poco leí que una gran empresa Simenens/Nokia/... había donado software de clustering a MySQL). Además al incorporar el código de SapDB dentro de MySQL promete resultar en un producto muy completo.

Aunque todo esto está en desarrollo, es algo que veremos en el futuro. Hoy en dia no considero a MySQL como rival a tener en cuenta para PostgreSQL, Firebird, SQL Server, Oracle, ....

Saludos.

[Julián]

O sea, que MySQL es una mierdecilla ¿no?

MySQL ya sabemos que no es igual que oracle o firebird, no hay que estudiar mucho para eso.

Pero tampoco hay que estudiar mucho para saber que el no ser igual, o el ser mas "pequeño", o el ser mas "simple", no es lo mismo que ser peor.

MySQL se usa sobre todo para aplicaciones web, que a menudo suelen requerir rapidez en la ejecucion de las consultas, por ejemplo, aplicaciones como estos foros.
Para estas cosas MySQL es fácil de usar y sencillo de mantener. Por ejemplo, en cualquier momento se puede hacer una copia del directorio /var/lib/mysql y ya tenemos una copia de seguridad sin necesidad de cerrar la bd ni nada parecio. Y la manera de gestionar los permisos es facilisima, incluso se pueden poner restricciones a direcciones IP y/o hosts.

MySQL esta hecha para este tipo de cosas, faciles, sencillas, y por eso no tiene todas esas cosas que si tienen otros servidores, o sea: menos caracteristicas, y mas velocidad.

El dia que MySQL se parezca a a esos otros servidores algunos tendremos que buscar alguna alternativa que cubra el hueco que dejará MySQL.

Por ejemplo: este sistema de foros (el phpbb) puede confiigurarse para trabajar con postgresql (tambien para MS SQL y algunos mas)
teniendo en cuenta que en clubdelphi.com se dispone de un servidor postgresql y tambien en la mayoria de sevidores que usan linux
¿porque aquí y tantos otros sitios no se usa postgresql y se sigue usando mysql?
¿será porque es mas fácil usar MySQL? eso creo yo.


¡Saludos!

[guillotmarc]

Empezado por Julián

O sea, que MySQL es una mierdecilla ¿no?

¿ Quien ha dicho eso ?. Yo seguro que no.

Empezado por Julián

MySQL ya sabemos que no es igual que oracle o firebird, no hay que estudiar mucho para eso.

Pero tampoco hay que estudiar mucho para saber que el no ser igual, o el ser mas "pequeño", o el ser mas "simple", no es lo mismo que ser peor.

MySQL se usa sobre todo para aplicaciones web, que a menudo suelen requerir rapidez en la ejecucion de las consultas, por ejemplo, aplicaciones como estos foros.
Para estas cosas MySQL es fácil de usar y sencillo de mantener. Por ejemplo, en cualquier momento se puede hacer una copia del directorio /var/lib/mysql y ya tenemos una copia de seguridad sin necesidad de cerrar la bd ni nada parecio. Y la manera de gestionar los permisos es facilisima, incluso se pueden poner restricciones a direcciones IP y/o hosts.

MySQL esta hecha para este tipo de cosas, faciles, sencillas, y por eso no tiene todas esas cosas que si tienen otros servidores, o sea: menos caracteristicas, y mas velocidad.

Nadie ha discutido esto.

Empezado por Julián

Por ejemplo: este sistema de foros (el phpbb) puede confiigurarse para trabajar con postgresql (tambien para MS SQL y algunos mas)
teniendo en cuenta que en clubdelphi.com se dispone de un servidor postgresql y tambien en la mayoria de sevidores que usan linux
¿porque aquí y tantos otros sitios no se usa postgresql y se sigue usando mysql?
¿será porque es mas fácil usar MySQL? eso creo yo.

Es una opinion, aunque yo no la comparto. Yo diria mas bien, que es simplemente porque lleva mas tiempo en la comunidad Linux. Y porque debido a eso esta mas extendido.

Saludos.

[kinobi]

Hola,

estoy de acuerdo con tu opinión, salvo con:

Empezado por guillotmarc

Yo diria mas bien, que es simplemente porque lleva mas tiempo en la comunidad Linux. Y porque debido a eso esta mas extendido.

la comunidad linux (hablando genéricamente, y especialmente entre desarrolladores) se inclina sobre todo por PostgreSQL (tómese el comentario con las oportunas reservas). Otro asunto es que la características de MySQL la hacen apropiada para muchos desarrollos web, y de ahí a convertirse en uno de los motores más populares (extendiéndose a otro tipo de desarrollos) hay un paso muy pequeño, ya que los servidores web son, en su gran mayoría, Unix y Linux.

Saludos.