MySql: ¿Una base de datos menor de edad?
 

Wop!

A raiz de un hilo planteado en el foro de IB en el que un usario planteaba dudas al migrar a Firebird y que hacía referencia a MySql como una base de datos para "proyectos pequeños", ha renacido en mí una duda que he tenido siempre: ¿Por qué todo el mundo se mete con MySql?

Excepto aquellos desarrolladores que han tenido larga experiencia con ella, la mayoría opinan que es un sistema rápido, pero que le falta robustez, características para poderse comparar con productos como Oracle, Interbase o SQLServer.

Pues a mi me parece que no!

¿Por que la nasa migró parte de sus sistemas a MySql cuando los tenía desarrollados?¿Porque no es una BD robusta?... a mi me parece que no!

Se ha argumentado que no tiene soporte para transacciones... a mi me parece que sí!

Tambien se ha dicho que no soporta integridad referencial... a mi me parece que tambien

La diferencia entre MySql y otros servidores es que en mysql, si prefieres prescindir de una característica para que la cosa chute más rápida, lo haces, sin más.

Bueno, el debate está abierto... hagan juego!

Hola,

el problema es que las características que citas han sido añadidas en sucesivas versiones y, a fuerza de inercia, la gente sigue teniendo prejuicios contra MySQL.

Saludos.

Hablamos de los "añadidos" de SQLServer? Por no nombrar las demas, todas han ido evolucionando!!!!!

Claro, claro, a eso me refiero. Lo que quiero decir es que a pesar de que ha evolucionado, y sigue haciéndolo, MySQL sigue siendo considerado erróneamente por muchos como un gestor de bases de datos menor, debido a que toman como referencia las características que tenía hace años y no las que tiene ahora.

Saludos.

Lamentablemente ya no es la base de datos gratuita que era, de ahí que PHP esté ya tomando alternativas como SQLite y similares.

Por las pruebas que hemos hecho, MySQL es la mas rápida con diferencia cuando tiene pocos registros, a la que le metes una tabla con 100 campos y un par de millones de registros, se le caen los pantalones.

Eso es una verdad a medias! MySql digue distribuyendose bajo licencia GPL, lo que sucede es que si lo que tú vas a programar no quieres que esté bajo esa licencia, entonces tienes que comprar el producto antes.

Pues no sé como habrás hecho esas pruebas, pero no son los datos que yo tenía. He estado buscando (sin suerte:rolleyes: ) una compartiva entre MySql, Oracle y SQLServer donde MySql quedaba casi a la par que Oracle y muy por encima que elde M$.

Algo que me gustaría agregar.

Hace no mucho vi aquí un hilo donde se preguntaba como realizar un sistema en Interbase que accediera a varias bases de datos. Yo no conozco Interbase pero me sorprendió sobremanera ver que no tiene una capacidad que MySql tiene casi desde sus inicios (sino es que desde el comienzo mismo) que es la de poder realizar consultas involucrando varias bases de datos (eso sí, en el mismo servidor).

Un saludo

¡Hola a todos!

Hace poco más de un año, cuando investigaba acerca de MySQL, me encontré con varios documentos que comentaban la carencia de transacciones en ese manejador de base de datos.

Creo que es una cuestión de sicología y mercadotecnia.

Imaginemos el escenario:

— ¡Oh! ¿Que será eso de "MySQL"? Suena como a una combinación de Mis Documentos y SQL Server. Tal vez sea uno de esos productos impopulares y torpes de Microsoft, como la libreta de direcciones o el asistente de Office. O tal vez es se trata de una de sus nuevas tecnologías de lentos y pesados DLLs, quizá su nuevo OLE, Toro, OLE. O quizás su versión ultra ampliada del lenguage SQL. ¿Querrá imponerlo al mundo? Seguramente estará lleno de Update Facking Patchs.

— ¡Oh! Parece que no es eso, de hecho está ligado con PHP. Ah, ya veo, aquí dice que se usa mucho en PHP porque es una base de datos ligera, sencilla y suficiente para la mayoría de las páginas web que todo lo que hacen es mostrar unos cuantos registros de algunas tablas. Inclusive, aquí dice que no maneja transacciones porque casi no se necesitan en páginas Web. Ojalá de todas formas PHP pueda trabajar con otras bases de datos mejorcitas.

Lamentablemente existen muchos productos buenos como MySQL o extraordinarios como Delphi, cuyo rechazo se basa en los prejuicios sicológicos que en muchas personas causan palabras y frases como "My", "SQL Server", "Pascal", "fuertemente tipificado", "lenguaje de mediano nivel", etc.

A veces hasta miedo me da decir que cierta función es sobrecargada (Overload). No valla a ser que se crea que es una función pesadota, lenta y con 53 parámetros por valor y 114 por variable (como las de Microsoft :D)

Recuerdo las palabras de Rodrigo Baca, mi exjefe de 1997:

— Vamos a optar por Visual Basic porque parece ser un lenguaje popular y fácil de usar.

La mercadotecnia es una camión sin frenos viajando cuesta abajo por una larga y vacía calle. Podemos esperar a que se estrelle (dentro de varias décadas) o ahorrar tiempo, adelantarnos, subir la pesada pero honorable cuesta y colocar en la cima la bandera de MySQL, Delphi, Oracle, Interfaz GH ;), y otros productos de calidad.

Atentamente,

Al González :).

Pues yo también tengo mis reservas con mySQL. Que haya resultado "casi" igual a Oracle en algunas pruebas.. lo considero "casi" imposible... aunque habria que ver los parámetros y por donde van tirando las balas...

He leido un documento de hace unos 3 o 4 años, donde ciertamente mySQL resulta la mejor base de datos para la gran mayoría de aplicaciones web, cosa que no discuto en el presente... pero en ese mismo test, interbase, para sorpresa de muchos (incluido yo) resultó ser la mas escalable (número de usuarios y número de registros almacenados).

En cuanto a las transacciones... según yo seguia sin tenerlas, o es que las tiene a partir de las últimas versiones. No se que tan desarrollado esté su lenguaje de triggers y stored procedures... ni cómo este su rendimiento (optimización) que por cierto es donde peor puede calificarse a Interbase (no he tenido tiempo ni oportunidad de evaluar a fb).

Lo cierto, es que, al menos yo, tengo relegado a mySQL para proyectos web, de donde no pienso moverlo en un furuto cercano... pero ni me he atrevido a probarlo para un proyecto de escritorio, multiusuario, etc, etc.

Habrá que hacer unas pruebas de nuevo... de hecho, yo tengo instalado mySQL, Oracle e Interbase en mi servidor... si alguien se prepara unas pruebas, con carga pequeña, mediana y grande, podemos llegar a nuestras propias conclusiones. Me envian los scripts... los aplicativos, y yo me encargo de correr los tests y publicar los resultados.

Hasta luego.

;)

Hola a tod@s:

Hace unos meses tuvimos que decidir, en mi empresa, qué base de datos usar para que los clientes accedieran por internet a una serie de información personalizada, sólo consultas, no pueden dar altas ni hacer modificaciones.

Hicimos pruebas con MySql 4 y con Firebird 1. Cuando había unos pocos miles de registros, MySql respondía muy bien, aunque Firebird no se quedaba atrás, sin embargo, cuando se pasó los 50.000 registros, normalmente Firebird respondía antes a las consultas y lo qué sí ocurría siempre es que cuando había más de 30 ó 40 usuarios conectados, siempre respondía mucho antes firebird, con gran diferencia.

Quizás a todos no les vaya igual, pero esa fue nuestra experiencia y hasta ahora nos va estupendamente con unos 80 usuarios conectados todo el tiempo, de media, y varios millones de registros.

Hicimos unas pequeñas pruebas con Oracle y nos resultó algo lenta en comparación y teniendo en cuenta su coste económico decidimos no usarla.

Hemos visto que MySql ha hecho grandes avances e incluso ahora, si tuviéramos que volver a decidir, también haríamos pruebas con MaxDb, que parece muy interesante.

En fin, que no hay nada definitivo, todo depende del proyecto a realizar, de los gustos, del precio e incluso de las manías personales.

Saludos para tod@s.

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.

Hola,

algunos comentarios:

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

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.

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.

Hola.

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

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

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

Hola,

Yo entiendo que no ...

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.

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.

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

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.

Hola.

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.

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 :D), 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.

Hola,

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.

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.

Como hemos visto, en la próxima versión 5, eso ya está previsto.

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.

Por lo que he argumentado anteriormente, no comparto tu opinión.

Saludos.

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.

pero eso es, en todo caso, un problema del proveedor del hosting, no de MySQL.

Saludos.

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.

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 :eek:.

Hasta luego.

;)

Hola,

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.

Hola.

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.

Hola,

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.

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 :D

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

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

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

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

Saludos.

;)

Hola,

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.

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

Saludos.

Hola.

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.

probad esto:

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.

Hola,

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.

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

// Saludos

Hola.

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.

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" ;)

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 ?

Saludos.

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

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

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.

Hola.

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.

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.

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 :

Entonces ya puedes realizar la consulta :

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.

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.

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.

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!

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

Nadie ha discutido esto.

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.

Hola,

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

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.