Barrapunto

La gran desventaja de MySQL siempre ha sido la carencia de prestaciones como la integridad referencial, las vistas, los procedimientos almacenados, las subconsultas.... y su ventaja la rapidez y el poco uso de memoria. Vamos, que parecía pensado para aplicaciones web, que no suelen tener grandes requisitos técnicos pero necesitan velocidad y que aguante muchos usuarios simultáneos.

Las nuevas prestaciones de MySQL 4 están muy bien y las de la próxima versión estarán mejor pero... al precio de reducir la velocidad y aumentar el uso de memoria. De modo que no sé cuanta gente los empleará en su nicho de mercado habitual. Yo mismo no puedo pasar mi aplicación a InnoDB si quiero que la web siga arriba. :-(

Ya veo que MySQL está mejorando notablemente, y que empieza a ofrecer características que las empresas requieren, pero de ahí a planteárselo como alternativa a Oracle!!.

Seamos serios, MySQL lo tiene crudo contra SQLServer y no digamos ya contra Oracle!.

Puede que MySQL pueda servir para determinadas tareas en entornos profesionales (sobretodo de backend en servicios Web), e incluso que muchas empresas se puedan plantear su utilización en producción (como sustituto a servidores de Bases de Datos antiguos y a sistemas basados en Access o bases de datos pequeñas), pero si se trata de aplicaciones “pesadas”, y con esto me refiero a aplicaciones que hagan un uso extensivo de la base de datos, o aplicaciones críticas, la verdad es que no veo que sea una base de datos suficientemente madura.

En la versión 5.0 habrá soporte para “Stored Procedures”(Oracle y SQLServer lo tienen desde hace tiempo, por no decir desde siempre), soporte elemental para cursores (Elemental?, Oracle lo tiene completo y más que sobrado), soporte real de VARCHAR, entre otros. Pero, esto son novedades, que seguramente carecerán de ciertas características, como es lógico en algo nuevo, y la verdad, en aplicaciones “grandes” esto no es tolerable.

En resumen, MySQL es una buena opción para determinadas tareas, siempre y cuando no requieran demasiado de una base de datos, y sobretodo si lo mas importante es la velocidad, pero no es una alternativa a Oracle, aún le falta mucho para eso.

Está claro que MySQL no tiene nada que ver con Oracle. También está claro que MySQL no le puede llegar en prestaciones a SQL Server, DB2 o cualquier RDBMS que querais, pero lo que sí que está claro es que su popularidad lo hace el sistema con más instalaciones en el mundo (esto NO es un dato, es una impresión). Nadie puede negar que dónde haya un servidor web cuyas paginas tengan que almacenar o manejar datos, es áltamente probable que haya un MySQL detrás. Esto no deja de ser una garantía.

Hay un nicho del mercado que está más que cubierto, casi sin darnos cuenta: Las bases de datos de escritorio. ¿Que sistema de Bases de datos puede competir con Access realmente?. Cualquier Oracle, PostgreSQL o Interbase es excesivo y no es comparable. Tampoco me vale sistemas que son anticuados por naturaleza (lease: dbase o similares). Aunque Access tenga sus virtudes, lo único que realmente le salva como sistema de B.B.D.D es que viene con MS Office, MS Office que está instalado (legalmente o no) en la mayoría de los PC con Windows de este planeta (desgraciadamente la mayoría de los PC). Esto es lo que lo hace ¿"potente"? ¿"interesante"? ¿"..."?. Pues como este es una gran baza la que tiene MySQL: popularidad.

Siempre pongo un ejemplo: Interbase (sustituyase por FireBird según el caso OpenSource VS Comercial). Es una joya, lo tiene todo y desde siempre, algo que la mayoría no pueden decir (p.e. en Oracle 8i no se puede usar la cláusula join en un select, hay q hacerlo a mano). ¿Por qué Interbase no es tan usado como debería ser? : no es el precio, cuesta igual que SQLServer (obviando la posibilidad de Firebird), no son las prestaciones (ya he hablado de ellas), no es la velocidad (preguntad a los que la usan)... Es lo mal que lo hizo Borland con su puñetera manía de no comercializar los productos en condiciones. Si Borland le hubiese puesto una buena campaña, ahora posiblemente estaríamos hablando de interbase en vez de otra cosa.

El hecho que cuando se le añaden opciones (vease: Integridad Referencial, Transacciones, Subconsultas o ahora los procedimientos almacenados y demás) le resta velocidad e incrementa el uso de memoria es innegable. Lo que también ha de saber aquel que lo haya usado de verdad es que todas estas herramientas pueden no usarse, sencillamente diciendo que tu tabla no es innodb. Entonces te encuentras con el MySQL veloz y pequeño que tenías en la versión 3.23, solo que mejorado por el paso del tiempo. Lo que era cierto hace 3 años lo sigue siendo ahora, solo que tienes la posibilidad de usarlo para otros menesteres.

Moraleja: Lo interesante es que poco a poco están haciendo del MySQL un RDBMS con todas las de la ley y manteniendo (para el que lo quiera) su tradición de rápido y pequeño. Me parece una acertadísima estrategia.

No hago mas que ver que mysql es lento comparado con oracle o que oracle es blablabla... pero vamos a ver, yo como desarrollador de aplicaciones para pymes con un volumen de datos lógico para una empresa de este tipo... que ventajas puede aportarme usar oracle frente a mysql? yo veo servidores web con grandes volúmenes de datos y cientos de usuarios trabajando a la vez y no parecen existir muchos problemas... o si que los hay?

Y es que la pyme es precisamente el sector mas importante a la hora de captar clientes... salvo esos ¿afortunados? que logran contratos de desarrollo con grandes empresas como ibm o telefónica... pero a esos el cobrarles diez o veinte mil euros mas les da risa... ¿o me equivoco? es posible

Sinceramente, prefiero ahorrarle unas pelillas al cliente que se va a quedar mas contento ahorrándose unos duros que si le cuentas las maravillas de oracle. O mejor aún, se le cobra un poquito mas y ese pico se dona a mysql o cualquier otro proyecto OS. ¿Soy el único que piensa así?

Algo que me ha llamado la atención es el tema de la replicación. ¿Acaso ahora se puede automatizar el mantener dos equipos con la misma información? Esto es genial para el tema de backups y demas.

Todas las bases de datos que se han mentado en la noticia y en los comentarios son maravillosas porque pueden hacer millones de cosas.

Sin embargo, hay mucha gente que las usa para bases de datos muy pequeñas como las de sitios web con poco contenido y sin muchas visitas, colección de discos, vídeos, libros..., lo cual es un desperdicio de recursos y eficiencia, pues sqlite puede ser el candidato idóneo en estos casos. Consume muy pocos recursos y es rapidísima. Hay frontends gráficos; esto la posibilita para ser una alternativa real a Access.

Si algún día tuviera que crear una base de datos de millones de registros y muchas consultas simultáneas mi elección sería una de esas super bases de datos. Para lo demás, sqlite es lo más efectivo, ¿estáis de acuerdo?

Los procedimientos almacenados, triggers, integridad referencial y transacciones cargan la responsabilidad de la integridad de la base de datos sobre el servidor, y liberan al cliente de dicho trabajo.

Esto, en general, es importantismo. El diseñador de la base de datos no necesita confiar en que el lado cliente haga las cosas bien, en general el servidor puede rechazar operaciones incorrectas. Sin embargo, tiene un precio: velocidad en las inserciones, modificaciones y borrado. Aunque no hagamos uso de estas características, si un gestor de base de datos las soporta, penaliza las modificaciones. Pureba a insertar 1000 registros en un MySQL de las primeras versiones y en un PostgreSQL sin utilziar triggers ni integrida referencia.... un abismo.

Yo no me atrevería a hacer un programa con datos sensibles sin las características avanzadas, especialmente una base de datos a la que el usuario puede tener acceso. Sin embargo, para una base de datos simple, en internet, donde sólo el programa que yo he hecho puede entrar, hay media docena de tablas, estoy dispuesto a renunciar a las características avanzadas (quizá, salvo transaciones) a cambio de velocidad.

Además, la verdad últimamente prefiero una arquitectura three-teer, (es decir, un servidor intermedio que recibe las peticiones del cliente y las manda a la base de datos) en lugar del clásico cliente/servidor. En el three-teer programas en el lenguaje que te da la gana, en lugar de en un lenguaje pobre y farragoso de SQL-XX. Y si a este cliente le quiero colocar un Interbase, al tro na un informix, y al de más allá un PostgreSQL, no tengo que reprogramar todos los procedimientos y triggers.

En resumen, hay dos tipos de bases de datos: a) Grandes, pesadas y fiables. b) Ligeras sin caracteristcas avanzadas y la fiabildiad en el cliente. No creo que MySQL haga bien en moverse de lo que era hasta ahora: Una base de datos ligera.

pues la respuesta sería que si, algunas si...

A mi una de las cosas que más me molestan de MySQL son ciertos comportamientos claramente no-estándar [sql-info.de], resultado de tener que añadir funcionalidades no planteadas en origen(ejemplo [mysql.com]), y que no se cambiarán a corto-medio plazo para no romper todas las aplicaciones que dependan de ellas.

En cualquier caso, coincido con la opinión mayoritaria: MySQL tiene su nicho y con todo el apoyo que está teniendo es posible que en unos años iguale en funcionalidades a PostGres/FireBird. Esperemos que vayan afinando también estas cosas.

Mysql no tiene futuro. Y no lo digo porque técnicamente sea buena o mala, lo digo por el tipo de licencia que le proteje.

No me salteís aún al cuello a defender la GPL, pues no hablo de la GPL. Hablo de los "pequeños añadidos" que tiene, los cuales entran en clara contradicción con la GPL. (¿Se invalidan entonces ambas licencias?).

En la web de mysql, vemos que hay que adquirir normalmente la licencia si vamos a trabajar con una aplicación propietaria que necesite una BBDD:

"The Commercial License is an agreement with MySQL AB for organizations that do not want to release their application source code. Commercially licensed customers get a commercially supported product with assurances from MySQL. Commercially licensed users are also free from the requirement of making their own application open source." (http://www.mysql.com/products/commercial-license. html).

Bien, por otro lado y observando la GPL:

"What is the difference between "mere aggregation" and "combining two modules into one program"?
Mere aggregation of two programs means putting them side by side on the same CD-ROM or hard disk. We use this term in the case where they are separate programs, not parts of a single program. In this case, if one of the programs is covered by the GPL, it has no effect on the other program.
Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL--if you can't, or won't, do that, you may not combine them.

What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged). "
(http://www.fsf.org/licenses/gpl-faq.html#MereAggr egation).

Visto esto además tengo una duda. ¿Están engañando esta gente a la "comunidad"? ¿Esta práctica la usan más compañias? Nos están "vendiendo" un producto como GPL para que la mejore la comunidad mientras que no es GPL.

Además, en cuanto ves esto, ves el impedimento que tiene para que una empresa lo adquiera (¿Para qué quiero gastarme dinero en mysql si ya tengo la otra? o ¿Para que comprar Mysql si Postgress es gratuita?).

Bueno, saludos y a ver si alguien me puede iluminar porque no sé si voy un poco perdido con esto ;)

Parece que la única aplicación que tienen las bases de datos es para casi todos vosotros que, como veo, trabajáis en bancos. Qué chupimaravilla, pero joder, cada cosa tiene un lugar de aplicación y creo que por aquí se debería entender cual es la de cual, es como si ahora me vengo a quejar de que Oracle es un armatoste porque no me viene bien para aplicar en mi servidor personal donde tengo un weblog.

Todo depende de lo que quieras hacer con ella. Estoy de acuerdo en que aún no es comparable con oracle, pero no es tan de juguete.
Sin ir más lejos, creo recordar que slashcode (barrapunto y slashdot incluídos) funciona con MySql por debajo, y el rendimiento parece bastante bueno.

Personalmente he usado sapDB, que viene a ser lo mismo, no creo que hayan cambiado muchas cosas en la versión 7.5, que es la que se llama MaxDB.
Es realmente una pasada, es muy rápido, tiene todas las cosas que puedes esperar de un gestor de BD profesional, y además ahora es libre. Esta si es una alternativa a BD más "grandes", como SQLServer, por ejemplo soporta: