Barrapunto

... Siempre que no lo empleen en grandes proyectos :P

Se supone que la herramienta tendría que ser la adecuada al problema y no "al prestigio" del que la usa.

MySQL puede ser un excelente producto o un pesimo producto. Dependiendo de su uso. Usar MySQL con una base de 1000 tablas, millones de registros y 300 usuarios concurrentes no creo que sea la mejor idea. Mas teniendo en cuenta que muchas de las novedades mas usadas en un sistema empresarial (Store procedures, vistas, triggers, tablas particionadas, etc), son muy nuevas en MySQL y habria que ver si tiene la estabilidad que ofrecen otros productos open source como Postgress o Firebird.
Pero si estamos hablando de una base chica, con muchos accesos de lectura y poca escritura, puede ser una excelente opcion.

Así como la ya obsoleta fama de que "java es lento", mysql tiene mala fama a la hora de implementar servicios transaccionales. Aún hay gente que dice que es una base de datos a medias cuando se la compara con postgresql. Por lo tanto, se la desprecia en aplicaciones grandes.

Hace unos días apareció un artículo de Martin Fowler donde cuenta la sorpresa que se llevó cuando supo que eBay no usaba transacciones gestionadas por Base de Datos ni llaves foráneas. Toda esa carga extra se le delega al programador porque a la escala de eBay, la Base de datos es el cuello de botella.

http://martinfowler.com/bliki/Transactionless.html [martinfowler.com]

Ahora, no se qué BD usa eBay (probablemente Oracle), pero dados sus requerimientos puede que mysql hubiera calzado más o menos bien.

La cosa es no cerrarse, sino evaluar caso a caso. (Esta clase de ejemplos son los que hacen que me ría cuando los fatalistas dicen que en un par de décadas los informáticos van a quedar obsoletos: Alguien sin el bagaje adecuado no sería capaz de tomar correctamente esas decisiones)

¿Es access la base de datos adecuada para grandes compañías?.
La respuesta es No, y sin embargo yo la he visto para pequeñas,medianas y grandes empresas.
Si access parece ser que es adecuada, ¿por qué no lo va a ser MySQL?.
El problema es el mismo que tiene php, que tiene mala fama para proyectos grandes.
Razones por la que usar mysql y no Oracle, así a bote pronto:
- Permite meter campos nuevos en mitad de la tabla ( muy útil cuando se añaden mejoras o cambios,al cabo de los años. Sin tener que hacer pasos intermedios para conseguirlo.
- Permite paginar resultados ( tanto útil para la web o para el escritorio ). ¿Qué es eso que si yo quiero mostrar solo, por ejemplo, los 10 primeros elementos de la tabla o tenga que hacer 3 consultas o tenga que meter todos los elementos en un array y luego de este coger los 10 elementos esos?.
http://asktom.oracle.com/pls/asktom/f?p=100:11:0:: ::P11_QUESTION_ID:127412348064 [oracle.com]
- No trae booleanos de serie. ( que si, que con un number o un varchar se puede emular, pero no es lo mismo)
- Su instalación, configuración y administración es muy engorrosa. ( no hablo de la versión express, aunque esta también ).
- Consume un porrón de recursos.
- Todo el mundo conoce la versión MySQL que viene en todas las distribuciones, pero hay más versiones:
http://www.mysql.com/products/ [mysql.com]. Por el dinero que te compras una Oracle, le encargas el soporte a MySQL y este te dejará un servidor acorde a tus necesidades(seas pequeñas o grandes ).
- .... ( poner aquí las mil y un motivo por los que Oracle llega a ser un tostón ).

Aquí teneis más razones:
http://www.mysql.com/why-mysql/toptenreasons.html [mysql.com]

Como todos ustedes saben la Wikipedia usa MySQL como base de datos....y la Wikipedia yo creo que (al menos la inglesa) ya debe tener algún que otro millón de registros en su base de datos...y a mi me parece que va bastante bien...y la carga que soporta es importante.

He estado buscando y algunos bancos de paises sudamericanos usan MySQL en sus bases de datos, por lo que el tema de la seguridad también debe aprobarlo, sino un banco no lo usaria.

Yo creo que el san Benito que se le ha colgado a MySQL no hay quien se lo quite...pero yo trabajo con MySQL y puedo decir que es una base de datos más que fiable y robusta.

Un saludo!

Tolito [elrincondetolito.com]

¿Cuando está una aplicación madura para las grandes empresas?.

Cuando esta va acompañada por un maletín.

¿Cuando estará MySql preparada para las grandes empresas?

Cuando sus licencias valgan los tropecientos millones que justifican un maletín.

--
Sólo los cutres usan bolsas de basura.

Yo creo que MySQL es adecuada para muchas grandes empresas cuando está siendo utilizada por muchas grandes empresas, tales como Google, Yahoo, Lycos o CNET Networks que la están utilizando para sus sistemas en producción.

Otra cosa es si es la más recomendable para todos los proyectos. Bien, yo hay cosas para las que no la recomendaría (no me imagino una base de datos de terabytes en MySQL) pero, en general, creo que es una buena opción. Sobre todo ahora que ya tiene cosas que en entornos empresariales se necesitan muchísimo: Triggers, Vistas y Procedimientos Almacenados.

El problema de que no se extienda mucho por las medianas y grandes empresas (que no sean de informática) y que por ello se crea que no está preparada para entornos empresariales es que no se obtiene un gran beneficio en una empresa de servicios/consultora (que es lo más extendido, creo yo) por ofrecer como servidor de base de datos MySQL mientras que ofreciendo MS SQL Server, Oracle, Sybase, etc..., siempre se obtiene un pequeño margen sobre el precio de las licencias. Vamos, que muchas consultoras ni se plantean ofrecer este producto a sus clientes porque no sacan a penas pasta.

No es lo mismo vender una licencia de Oracle para una empresa por 50.000 cuando a Oracle Corp. se la sacas por 40.000 y la empresa se queda esos jugosos 10.000 que, con suerte, conseguir venderle una licencia de MySQL (después de decirle que es software libre y el cliente no se entera de porque tiene que pagarla) por 5000 , cuando la licencia más cara de las caras vale 3.995 .

Esta es la causa por la que mucha gente cree que MySQL no está extendida empresarialmente por no estar preparada para dichos entornos.

Yo es que de las bases de datos no tengo mucha idea, ¿alguien podría explicar brevemente cuales son las ventajas e inconvenientes de MySQL enfrentadas por ejemplo a PostgreSQL? Porque lo único que veo son comentarios que dicen que dicen ejemplos de empresas que lo usan, pero eso tampoco aclara mucho, porque habría que saber cuanto se han modificado.

Oracle nos dió la clave, seguramente sí, Oracle (al igual que SAP) nunca se ha caracterizado por bajar a la pequeña y mediana empresa (por mucho cartelito que se pusiera en barajas de "Ahora Oracle para la PYME"), viven de un gran porcentaje de mercado que los sobrevalora y que pagan autenticas fortunas para poder decir entre vichy y vichy que "ELLOS USAN ORACLE", teniendo eso en mente ¿porque quiso compra Oracle a MySQL? a mi parecer los ingenieros de oracle aconsejaron a sus instancias superiores zamparse a MySQL con patatas antes de que sea una alternativa real a su producto, algo vieron o creyeron ver que les hizo pensar que de mayor MySQL sería muy caro de pagar (incluso para ellos).

Joder, siempre la misma historia... "¿Es el software X el mejor para todo?".. NO. Cada proyecto tiene sus requerimientos, y el gestor de base de datos a usar será aquel que más se ajuste al proyecto.

No usaré Oracle, Postgre o SQL Server para hacer un blog de unas 5000 páginas servidas al día, pero sí usaría Postgre, por ejemplo, para una base de datos con mil tablas y 1.000.000 de páginas webs servidas al día.

Lo que sí está claro es que MySQL no tiene rival para proyectos pequeños (webs sencillas, como blogs o foros), pero para proyectos más grandes dar el salto a Postgre daría muchas ventajas.

Por lo visto MySQL se comporta muy bien para bases de datos pequeñas, es rápida pero no muy escalable, al aumentar de tamaño la base de datos la pérdida de rendimiento es considerable. Para bases de datos grandes PostreSQl se la come con patatas [blogspot.com] Si por lo contrario como has dicho solo vas a usarlo para un blog o foro probablemente ganes algo de velocidad usando MySql.

Totalmente de acuerdo. Postgres es una maravilla comparable a cualquier sistema gestor de bases de datos comercial. En cuanto al clustering ( entendiendo como tal el que dos servidores distintos puedan acceder simultáneamente a la misma base de datos ) mi idea era que Postgres sencillamente no lo soportaba, aunque sí exitía alguna herramienta de terceros; pero mi práctica con Postgres está algo desfasada, y tampoco tengo ganas de mirar como anda ahora el tema.
Si te interesa dicho tema, sí hay un gestor de bases de datos Open Source con probada eficacia en el soporte de clusters. Se trata de Ingres [ingres.com], que desde hace poco ha pasado a ser distribuida bajo la GPL.

¿Has intentado poner Firebird en un cluster con varios nodos? ¿Y bases de datos en espera por si se cae una que salte la otra con sistema de archivos en clúster? Interbase si lo soporta pero Firebird no.

MySQL, sin embargo, si soporta instalaciones en Cluster, así como otras bases de datos que se utilizan en entornos empresariales: IBM DB2, SQL Server, etc...

No puedes poner una base de datos en una única máquina en una empresa. ¿Si mañana se cae esa máquina con que trabajan?

En el artículo se habla de bases de datos empresariales y, supongo, a nivel de empresa media/grande. Firebird está bien para pequeños proyectos, pero no para cosas medianamente complejas.

PostgreSQL, según mi experiencia, se comporta igual con unos cientos de megas que con unas decenas de gigabytes.

No he tenido la oportunidad de probar PostgreSQL con más de 80 GB de base de datos pero, con sinceridad, los tiempos de respuesta en operaciones DML y DQL son más o menos los mismos en una base de datos con 5 GB (versión inicial) que con 80 GB (con datos de migración).

Bueno, teniendo en cuenta que es 16 veces más grande, claro.

Para grandes empresas quiza sea mejor elegir db2 o teradata.
El nicho de oracle es la mediocridad. Demasiado pequeño para sitios grandes. Demasiado grande para sitios pequeños.
Ademas, si lees oracle al reves veras su autentica esencia :-O

Estoy de acuerdo... y lo estoy porque yo era uno de los que se empeñaban en usar MySQL, de lo cual me arrepentí varias veces.
En un trabajo lo elegí sobre todo porque entonces no había versión nativa de Postgres para Windows. Después de crear el esquema de la base de datos en Mysql y configurarlo todo para que la usaran las aplicaciones cliente, necesitabamos hacer una consulta medio complicada y nos daba error, y tras investigar un poco resultaba que Mysql no tenia subconsultas!! Esto era por la version 3.23 creo... la 4.1 ya lo tenia. Pero luego en mi trabajo actual la volvi a elegir, porque por entonces ya la 4.1 era estable, y me volvio a pasar lo mismo con las Vistas... no lo ha tenido hasta la version 5, que por entonces era beta...
El problema es que para cuando reparas en eso ya llevas trabajo hecho, y como tengas que cambiar de SGBD todo ese trabajo hay que tirarlo a la basura. Y es que no se me habia pasado por la cabeza que un SGBD tan aclamado como Mysql no tuviera vistas o subconsultas, asi que ni me molesté en comprobarlo de antemano... si es que eso lo tiene hasta el Access

Ahora Mysql ya tiene todo esto pero no lo elegiría nunca en un nuevo proyecto, vete a saber que funcionalidad básica de bases de datos le falta ahora...