MySql: ¿Una base de datos menor de edad?

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