Barrapunto

Debian Bug#188723: license changes / GPL vs. LGPL / GPL vs. OpenSSL

Muy chungo. De qué sirve una biblioteca GPL si está lincada a una biblioteca incompatible con la GPL como OpenSSL, lo cual hace que otros programas GPL no la puedan usar?

MySql ha apostado desde el principio por sacrificar la funcionalidad en aras de conseguir mayores prestaciones y solidez. Examinando la comparativa, se puede deducir que, afortunadamente, sigue haciéndolo.

En un gestor de bases de datos están reñidos la funcionalidad y el rendimiento. Es fácil comprender que las transacciones serán más rápidas si no necesitan comprobar nigún "constraint", ni desencadenar ningún "trigger". Así mismo, será también más rápida una consulta si no existe "integridad referencial". Lo difícil es encontrar una buena síntesis entre funcionalidad y prestaciones, y la bondad de este compromiso depedenderá de la labor específica a la que esté orientado dicho gestor.
Es decir, en un entorno de producción que necesite una gestión de datos sin muchas complicaciones funcionales, pero con fuertes requerimientos de concurrencia y velocidad ( y me atrevería a decir que son la mayoría ), es mas eficaz - más "profesional" - un gestor que sacrifique la funcionalidad para obtener un mayor rendimiento.
Por el contrario, si existe un desarrollo activo de la "lógica de los datos" ( entendiendo por tal todo el aparato lógico que puede desarrollarse dentro del gestor de BBDD, como triggers, constraints, procedimientos almacenados, funciones integradas, funciones de usuario, tipos de datos de usuario, etc. etc. ) es cuando se necesita un gestor de BBDD que te ofrezca dichas funcionalidades, aunque su rendimiento sea menor.

Puedo estar equivocado, pero en mi opinión, la mayoría de los gestores de BBDD instalados se encuentran en la primera situación. Es decir, la mayoría de los Oracles y DB2 que andan funcionando por ahí, están sirviendo a una o dos aplicaciones ( o un conjunto integrado de ellas como maxi/mini ERP's ), en las que es importante el rendimiento, mientras que sus potentes funcionalidades, incluidas las posibilidades de Orientación a Objeto, no se usan en absoluto.
En esas circunstancias, sería conceptualmente acertado recomendar el uso de un gestor de BBDD como MySql. Digo conceptualmente, porque la mayoría de los paquetes de gestión te imponen su gestor de BBDD, o como mucho, te dejan escoger entre dos o tres, que son los de siempre, y entre los cuales no se suelen encontrar los gestores de BBDD 'Open Source'.
Pero eso no quita, para poder mantener la opinión de que, en la mayoría de los entornos de producción, sería más "profesional" un gestor como MySql que un Oracle, un DB2 o un SQL Server. Por supuesto que la gran mayoría de los gerentes, o de las personas que aprueban los presupuestos de compras de los departamentos de Sistemas, opinan exactamente lo contrario, pero las razones en que se suelen basar no acostumbran a tener fundamentos muy racionales.
Lo que es más triste, es que hay muchos profesionales de Tecnologías de la Información, que opinan exactamente lo mismo que ellos, y con razones de parecido fundamento.

Es verdad, si ponemos esas exigencias ya podemos usar cualquier cosa.

Cuando mysql sea como postgresql usaremos versiones antiguas de mysql.
Cuando necesitemos una base de datos como postgresql usaremos postgresql.
Lo bueno de mysql es que, en muchas aplicaciones, es más útil que otras bd más completas.
También podríamos usar Oracle en vez de LDAP, pero usamos LDAP cuando es lo más conveniente.
O podríamos ir en automóvil al supermercado de la esquina, pero solemos ir andando.

Yo he utilizado muchisimo oracle y te puedo decir que prefiero mysql. Es cierto que tiene soporte para muchas más cosas, pero esto no siempre es necesario utilizarlo. Estos son, según mi experiencia, las desventajas de oracle:

1) Dificultad de configuración. Tiene miles de parámetros que es imposible saberse si no has hecho un curso de oracle (que además cuestan una pasta)

2) La configuración por defecto da muchos problemas. Si no pones suficiente memoria de SHARED_POOL, el servidor se viene abajo con mensajes "cannot allocate xxx bytes of shared memory". En mysql, si pones poca memoria simplemente va lento, pero no peta. Otro de los parámetros que da problemas es el número de cursores.

3) La documentación de su web es demasiado extensa y poco clara. Hay decenas de documentos, no sabes en cuál buscar, y además el SQL reference es de lo peor, con los globitos y las flechitas es imposible seguirlo. La doc de la mysql es muy clara aunque eso sí a veces se queda demasiado corta.

4) Imposibilidad de hacer ciertas cosas, como añadir una columna en una tabla en el medio (no al final), o cambiar el nombre de una columna.

5) Dificultad de administración. Algo tan sencillo en mysql como mirar los índices de una tabla (SHOW INDEX FROM), en oracle se traduce en hacer un SELECT en dos tablas internas (user_indexes y all_indexes o algo así). Otro ejemplo es el de los EXPLAIN PLAN, tan sencillo en mysql (EXPLAIN ) y tan complicado en oracle (es necesario crear una tabla especial PLAN_TABLE, y hacer algunas cosas más).

6) El sqlplus está a años luz en facilidad de uso que la utilidad mysql. No tiene un history (tipo bash), no puedes volver hacia atrás según escribes con las teclas de cursor (al menos en solaris), tiene un tamaño de línea máximo...

En fin, yo he utilizado las dos bases de datos, y la mysql nunca me ha dado problemas. La oracle sí.

Por si resulta de interés, MySQL implementa las subconsultas en la versión 4.1 (en estado alpha) y los procedimientos y triggers se calculan para la versión 5 (de la que nos podemos bajar el código, aunque aún no hay binarios).

...y de hecho, es lo que digo siempre en estos casos: a MySQL no le falta funcionalidad, le *sobra*.

Si alguien quiere/necesita SQL92 y todos los pitos y flautas, que use/potencie Postgres, que para eso está, y dejen MySQL para quien no necesite más que un "glorified filesystem manager", como a veces se le ha dado en llamar (y conste que somos muchos los que lo necesitamos, basta con mirar a la inmensa mayoría de los sitios web dinámicos, sin ir más lejos). El ejemplo que tú pones es especialmente clarificador: estructuras de datos relativamente simples con potencialmente muchos accesos concurrentes, en su mayoría de lectura, es el "nicho natural" de MySQL, si por darle más funcionalidad me lo sacan de este nicho, flaco favor me hacen. Para otros nichos, también existe una herramienta de licencia libre y buena calidad domo es Postgres, y el buen administrador sabrá escoger la herramienta adecuada para el nicho preciso.

En realidad (y esto es sólo una opinión personal) al dueto mysql/postgre les iba muy bien cuando eran *realmente* libres (de espíritu, no sólo de licencia): cada una tenía su nicho y propendían a ser el mejor software libre de su categoría en él. En el momento en que Nusphere ha metido mano, busca obtener la mayor cantidad de dinero y han decidido que eso no se consigue buscando la excelencia en *un* nicho, sino siendo mediocres en muchos, de ahí que se esté viendo cómo MySQL está dejando de ser lo que tradicionalmente era (sencilla y rápida) para tratar de entrar en otros nichos aumentando sus prestaciones (con seguridad a costa de la sencillez de administración, velocidad y estabilidad).