Barrapunto

> si se combinan en un entorno serio con una cabina de discos scsi en RAID
> y un buen microprocesador con mucha memoria ...

y ya puestos le metes oracle y te queda de miedo

MySQL seria? desde cuando? MySQL es un front-end pseudo-SQL y que funciona en red para ficheros de datos, no es un servidor de bases de datos real. Rapido? tiene que serlo, cuando necesitas hacer 4 consultas en su limitadísimo pseudo-SQL para hacer lo que en Firebird o PostgreSQL haces en una consulta de SQL92 estándard, y encima sin garantizar ni la integridad referencial ni la atomicidad ...

Entrañable, sigo sin entender por qué son los dueños del mercado. Facilidad de uso? FireBird DESTROZA a mysql en ese sentido... precio? tampoco... en fin

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.

Utilizamos Postgres y Mysql desde hace 3 años. Postgres se encarga de la producción y de los almacenes (transacciones, triggers, subconsultas, 5 GB), mientras que Mysql se encarga del correo y del phpGroupWare, y de la web de la empresa. Las dos funcionan bien, pero cada una sirve para lo que sirve. Me gustaría ponerme en contacto con gente que use Postgres (ifc380@yahoo.es)