Oracle pone el precio de MySQL por las nubes

Oracle ha publicado una lista de precios que confirma algunos temores de los usuarios de la base de datos MySQL. La empresa de software ha eliminado la suscripción más básica que ofrecía Sun, de 599 dólares por servidor al año dejando la suscripción estándar en 2.000 dólares. Esta opción estaría disponible para cada servidor con uno y cuatro sockets, pero en el caso de servidores con cinco o más sockets el coste se elevaría a 4.000 dólares.

[#2 llamamepanete]

Aclaración: MySQL sigue teniendo una versión Community, que sigue siendo gratuita ( mientras que a Oracle no se le cruce el cable, obviamente ). De lo que se habla en la noticia es de la suscripción anual que se exige para las versiones Standard, Enterprise y Cluster, que incluyen soporte, funciones más avanzadas y "software adicional" en las ediciones Enterprise y Cluster.

A este paso va siendo hora de mirar a MariaDB ( http://mariadb.org/ ) porque el futuro de MySQL lo veo incierto en manos de Oracle.

[#27 goticompulsivo]

#2, el problema principal y que echa "patràs", es que no podrás disponer del motor InnoDB en la versión gratuita.

[#52 Desactivado]

#27 A mí también me lo pareció pero no es como dices.

La versión "Comunity" sigue teniendo todas las características "sin capar". Ahora, búscate la vida para el soporte.

[#36 Desactivado]

#2 Microsoft también tiene una versión grauita de SQL server

[#38 llamamepanete]

#36 ¿Y también tiene un SO libre y gratuito en el que ejecutarla?

[#84 howl]

#2 ¿A este paso? ¿Ahora? Mal vamos sino lo era ya. Hay una sola cosa que hace que desde que salió MariaDB fuese un si o si a migrar a dicho gestor, que los desarrolladores que daban vida a MySQL se lo empezaron a dar a MariDB, el resto de motivos aparecen de este primero con todo lo que han ido implementando en el tiempo.

[#4 Desactivado]

Pues si se ponen muy tontos, nos vamos a Postgresql y tan felices. Es Open Source y yo tengo varias páginas corriendo en Postgresql y me dan los mismo problemas que la de MySQL: cero.

[#8 llorencs]

#4 Y Postgresql es bastante más potente que MySQL en mi opinión, aunque hace mucho tiempo que no miro MySQL, creo que aún sigue siendo inferior.

Ahora sí, MySQL solía ser más rápido que Postgres, pero creo que con las versiones nuevas de Postgres ha cambiado. Luego Postgres usa el mismo lenguaje que Oracle, pl/SQL, lo cual es una ventaja y más o menos pretendía ser una base de datos comparable a Oracle, lo que es seguro es que supera con creces a SQL Server.

[#10 LarryWalters]

#4 y #8: el único problema de PostgreSQL (es más potente que MySQL), es la escalabilidad. MySQL es más fácil de escalar, por eso es muy usado en entornos web. De todas formas se espera que PostgreSQL mejore en este sentido.

[#11 kahun]

#10 Exacto, PostgreSQL es mucho mejor que MySQL aunque en las últimas versiones ha ido añadiendo muchas de las cosas que le faltaban pero la mayor ventaja de MySQL es la escalabilidad, que es lo que más se busca en entornos web.

Una alternativa bastante prometedora es Drizzel: https://launchpad.net/drizzle

[#21 cosmonauta]

#10 ¿cual es el problema de Postgres con la escalabilidad? Aguanta más carga y desde la versión 9 tiene replicación.

[#29 kahun]

#21 Exacto, desde la versión 9.

[#65 LarryWalters]

#21 y #32 Ok, no sé si en la versión 9 la escalabilidad es más ágil, vivo en la 8.3 hace ya tiempo.

[#71 LarryWalters]

#21 y #32 Tenéis razón. Yo hablaba sin conocer las novedades de la 9. Hablaba con conocimiento de causa por un proyecto hace 1 año y pico, en el que se analizaron las posibilidades de las bases de datos posibles. Se utilizó postgreSQL finalmente, ya que la escalabilidad no era un punto muy importante a priori.
Las características nuevas que digo:
1. Hot standby. El usuario será capaz de crear una base de datos secundaria “en espera” únicamente para veloces consultas de sólo lectura. Esto es similar a DataGuard de Oracle y una de las características más solicitadas por años.
2. Streaming replication. Este es el llamado “segundo gran salto” de PostgreSQL. Con esta característica el DBMS archivará datos de manera continúa (en lo posible, sin tener que llevar un registro), lo que será muy útil en instalaciones que busquen ofrecer alta disponibilidad con excelente desempeño.

editado:

visto en Bitelia.

[#32 juanac]

#10 #19 referencias (actuales) por favor

[#23 Desactivado]

#4 #8 No está bien compararar mysql y postgre porque normalmente se deberían utilizar para cosas diferentes. Mysql (con mysam) es muy rápida, aunque tiene limitaciones muy básicas en cuanto a la capacidad de las tablas (aunque con inodb esto mejora considerablemente). Postgre es muy estable con muchos datos, pero es algo más lenta.

Depende del escenario que te vayas a plantear.

[#50 mr_b]

#4 PostgreSQL está muy muy bien. De hecho, en versiones anteriores a la 5 de MySQL le daba mil vueltas a esta. Ahora ya están bastante a la par.

El problema de PostgreSQL es que para contar registros (select count(*) from...) se eterniza (no usa una variable interna con su número, como hace MySQL).

[#35 llamamepanete]

#30 La escalabilidad es una propiedad de los sistemas de información y se entiende como la capacidad para adaptar su rendimiento a la demanda.

Dicho de otra forma, cuando tu sistema tiene 100 usuarios, pues lo normal es que no tengas problemas, ¿pero que pasa cuando tienes 100.000, y cuando tienes 1.000.000? La escalabilidad es la propiedad de tu sistema de permitirte crecer de la forma más sencilla posible para atender el crecimiento de la demanda.

Es un tema verdaderamente complejo, porque tiene que ver tanto, en la escalabilidad intrínseca del código, es decir, ¿cómo afecta el crecimiento del sistema al rendimiento? No lo afecta ( esto es irreal ), lo afecta de forma logarítmica ( esto es bueno ), lo afecta de forma lineal ( esto es normal ), lo afecta de forma exponencial ( esto es malo ).

Así como, una vez llegado al límite de capacidad del nodo, ¿qué posibilidades tengo? Escalado vertical ( más hardware al nodo ) y escalado horizontal ( más nodos ). En el primero de los casos, ¿ese nuevo hardware va a ser aprovechado o hay cuellos de botella que impiden que se aproveche realmente? P.ej si la escalabilidad del software se degrada de forma exponencial, perderé rendimiento siempre, por mucho hardware que aumente en el nodo.

En el segundo de los casos, el escalado horizontal, tiene que ver con montar clusters, ¿es posible montarlos? ¿es fácil admnistrarlos?.

MySQL es muy bueno escalando verticalmente y la tecnología MySQL Cluster permite un buen escalado horizontal.

[#40 Desactivado]

#35 No conozco la tecnología de clustering de MySQL, pero conozco bien la de OracleDB y también tiene un buen escalado horizontal desde Oracle RAC (a partir de la versión 9i).

Creo que la clave está en el funcionamiento transaccional, algo relativamente nuevo en mysql y bastante maduro en Oracle (desde la 7, creo recordar, tras la compra de hhmmmm.... estos del VMS, creo recordar que era la BD del SO VMS de Digital, pero no estoy muy seguro del todo)

[#46 llamamepanete]

#40 MySQL no es el mejor haciendo clusters, eso lo "copio" de "Oracle", por necesidad del mercado, pero sí que crece muy bien verticalmente.

[#72 AlphaFreak]

#40 RdB. Oracle la sigue vendiendo. No sabía que hasta la compra de RdB Oracle no fuera transaccional. Lo que me contaron en su momento es que lo que buscaba Oracle era el optimizador dinámico del RdB.

[#73 Desactivado]

#72 Es posible, hablo de oídas y de hace algunos años...

#60 ¿Y no crees que esta estabilidad puede estar relacionada con los bugs, o mejor dicho, con la ausencia de éstos?

¿Cuantos parches hay que aplicar a un HOST a lo largo de toda su vida y cuantos hay que aplicarle a una BD Oracle en 1 año?

[#74 AlphaFreak]

#73 ¿Cuantos parches? Bueno, en el mundo mainframe se llaman PTFs... y se aplican un montón. El orden de magnitud probablemente esté en torno a centenares cada año. Y algunas de las cagadas son de órdago!

Más que un tema de bugs (todo el software los tiene, con la excepción de casos muy, muy concretos en los que se aplican métodos de desarrollo fuera del alcance de casi todo el mundo), es un tema de metodología. En el mundo mainframe todo se orienta a la disponibilidad. Las ventanas de cambios estan muy bien establecidas. Cada intervención que se haga tiene que tener prevista una marcha atrás. Debe estar documentada y supervisada. Y, normalmente, la persona que la aplicará será un operador, no el mismo que la ha escrito. Eso permite detectar muchos fallos, corregir la mayoría y, en general que las cosas estén más claras. Como contrapartida, propagar cualquier cambio en un entorno mainframe es una tarea más pesada y más lenta. Pero no se puede tener todo

Y no digo que no haya entornos de tipo medio en los que se actue de igual forma, que los hay. Todas las generalizaciones son incorrectas por naturaleza...

[#75 llamamepanete]

#74 Personalmente opino que la estabilidad de un entorno HOST no es tanto el entorno en si, como la operativa de ese entorno, debido a su criticidad. Si a un entorno Linux Enterprise, le aplicas unas buenas prácticas, ITILv2/v3 por ejemplo, obtendrás una estabilidad y una disponibilidad muy alta, todo irá muy planificado, habrá segregación de entornos y tareas, procesos de gestión de cambio y entrega, etc.

Otra cosa es que por herencia, los entornos HOST permanezcan en su posición natural y se sigan usando. Mientras que los entornos genéricos Linux/Windows por herencia se destinen a tareas menos críticas, y por herencia esas tareas menos críticas esten mucho menos planificadas entorno a buenas prácticas.

Por tanto creo que en la base compartimos la opinión. Por cierto tus intervenciones son muy buenas y bastante alejadas del fanboyismo meneante medio. Mis más sinceras felicitaciones

[#77 AlphaFreak]

#75 Correcto. Esas prácticas tocan mucho los huevos, pero son necesarias y sus beneficios son evidentes.

[#67 leviatan]

#35 ahí le has dado... muy buena visión la tuya. Es el modelo hacia el que irán poco a poco todas las herramientas para empresa: software abierto y gratuito pero con soporte y tuneo a precio de oro. Personalmente creo que este modelo beneficia a todos, los que critican a Oracle y su política son los mismos que identifican OpenSource con TODO GRATIS, un modelo que no es sostenible.

¿A que a nadie de los que critican les importaría dar soporte de calidad a 1000€/día o hacer un pequeño desarrollo a medida (de calidad) por 100000€? Pues es algo que gracias a esta política de software abierto va a estar al alcance de cualquiera que se lo curre y consiga crearse un prestigio dentro de la comunidad...

[#1 francisco]

A ver, subirá el precio del soporte, si lo quieres usar sin soporte lo puedes seguir usando y si otra empresa quiere dar soporte más barato puede hacerlo sin problemas.

Es una mierda que Oracle tenga MySQL pero o me equivoco o no puede cargarselo tan rápidamente.

Otro tema es que a lo mejor 600 $ al año era un precio muy bajo que no se puede rentabilizar.

[#3 llamamepanete]

#1 No te había leído antes de enviar. Por matizar, no sólo se sube el precio al "soporte", versión standard, sino que también se incrementa el precio de las características avanzadas de las versiones Enterprise y Cluster.

En cuanto a si Oracle puede "matar" a MySQL, podría discontinuar el proyecto en el momento que quisiese. En ese caso, lo normal es que se hiciese un fork de la versión Community y se continuase desde ese punto, como por ejemplo, ya sucedió con MariaDB en el momento que Oracle compró Sun.

Sobre si los 600$ al año eran cantidad suficiente o no lo eran, por ponerte un ejemplo relativamente equivalente, una suscripción básica a RedHat para su RHEL cuesta 349$, la standard 799$ y la premium 1.299$.

[#5 antxon.urrutia]

#3 No sé yo si podrían descontinuar el desarrollo y soporte de MySQL tan fácilmente. La EU siguió de cerca la compra de SUN por Oracle y uno de los miedos en la compra era el futuro de MySQL el cual Oracle prometió que seguiría desarrollando. Uno puede pensar 'una vez metido...', pero no creo que la EU sea tan 'facil'

[#60 AlphaFreak]

#51 Permíteme que te corrija yo (Systems Programmer en z/OS) a ti El lenguaje de scripting por excelencia de un mainframe es el REXX (http://en.wikipedia.org/wiki/REXX). El JCL es un lenguaje de control de trabajos, concepto que no tiene equivalencia en sistemas Unix ni Windows, con funciones de scripting muy básicas (ejecutar o no un programa o "paso" en función del resultado de los pasos anteriores).

En la actualidad puedes programar contra DB2 usando casi cualquier cosa. Evidentemente, puedes usar lenguajes 3GL (C, PLI, COBOL), puedes usar java, PL/SQL (aunque IBM lo llama SQL/PL) y el mencionado REXX. Las versiones LUW (Linux-Unix-Windows) de DB2 te permiten usar los lenguajes de scripting más conocidos (python, perl, ruby, etc...) y los drivers JDBC para DB2 son de tipo 4 (te sirven en cualquier JVM).

Por cierto, existe una versión gratuita (no libre) de DB2 (DB2 Express-C) que os podeis descargar y usar en entornos de producción (http://www-01.ibm.com/software/data/db2/express).

#58 La razón de que los hosts no solo sobrevivan, sino que de hecho crezcan, es que a nivel de estabilidad no hay color. Cualquiera que haya trabajado en una instalación en la que coexistan entornos mainframe y entornos medios (Unix/Windows/Linux, da igual cual) habrá sido testigo de que en el lado "medio" se vive en una especie de crisis permanente, mientras que en el lado mainframe las cosas son bastante más tranquilas...

[#64 MycroftHolmes]

#60 Aceptamos barco . Como experiencia personal, he trabajado en 4-5 grandes empresas (como externo) y jamás lo he visto usar (el REXX)
La equivalencia del JCL a scripting precisamente lo puse porque a nivel de "usuario", básicamente lo único que puedes hacer es planificar JOBS, que ejecuten trabajos

De todas formas, positivazo, muy currado el comentario
¿La versión gratuita se puede usar en entornos de producción con mucha carga de trabajo? Se que en teoría si, pero hablo a nivel práctico ¿Aguanta como aguanta Oracle o DB2?¿IBM como te lo licencia?
Lo pregunto porque anduve por la web, y no encontré nada al respecto (tampoco me maté a buscar )

Y sobreviven porque aunque sean caros de cojones, hay que ver como mueven algunas transacciones. Yo he visto cargas de varias decenas de millones de registros, con controles de integridad y toda la pesca, en cuestión de minutos, y niquelado
He visto crear "ficheros de texto" de varios gigas de tamaño con total alegría, y siendo un JOB completamente residual en el sistema. Lo dicho, una pasada

[#70 AlphaFreak]

#64 No es adecuada para cargas muy altas. Si no me equivoco, tiene una limitación a dos cores y un máximo de 2GB de memoria. Eso no quiere decir que no puedas meterlo en una máquina más potente; simplemente no usará más que esos recursos. De todos modos, hace unos años hice un pequeño estudio comparando Oracle y DB2 (en Unix) y DB2 era (en precio de lista) ligeramente más barato que Oracle.

Mira el enlace que pongo más arriba - http://www-01.ibm.com/software/data/db2/express/ - y podrás encontrar la información acerca de DB2 Express-C que necesitas.

Por cierto, el REXX se usa para automatizar procesos y, sobre todo, para construir aplicaciones ISPF (esas que te gustan tanto ;)). Si te dedicabas a CICS o a IMS es normal que no lo vieras, pero seguro que lo utilizaste un montón (la mayor parte de los paneles ISPF tienen un script REXX detrás).

[#18 shinjikari]

Django + Postgres PsychoPG.

[#12 atzu]

Aquì està la lista de precios, la querìa meter ayer como noticia pero habria sido microblogging: http://www.mysql.com/products/

[#55 llamamepanete]

#48 Yo no soy DBA, pero por mi trabajo algo tengo que chafardear en esos lares, y lo que yo veo es que Oracle es tecnológicamente superior a DB2 como conjunto, quizá la potencia de DB2 en gestión de BBDD sea superior, mejores límites ( la última vez que lo miré ), pero en la gestión Oracle ofrece "mejores" tecnologías: rac. vs. purescale, particionamiento ( en db2 un poco verde ), etc.

Para mi el gran inconveniente de Oracle es su complejidad y que se entromete mucho en el SO, hay tareas que debería delegar al SO que no delega. En definitiva que te exige un DBA que sea al tiempo Sysadmin, cosa que en DB2 está mejor particionada.

[#58 Desactivado]

#55 Totalmente cierto.

Pero para mí, el gran inconveniente de Oracle, son sus bugs. Muchísimos más comparados con DB2. Es por esto que en aplicaciones bancarias hay tanto HOST. (Aunque debo decir, que mucho se está migrando ya a Oracle)

[#34 Desactivado]

Pues perdonad, pero lo veo como una espécie de experimento de Oracle, que si sale bien puede resultar en una versión de Oracle DB"comunity" y pagar sólo las licencias que aportan el soporte.

Hace algunos años, se rieron de mí en una ponéncia que dí del COURE (Congreso de Usuarios de Oracle España) sobre Oracle y la hipotésis de una tendencia a que se convierta en software libre en un futuro y se pague sólamente por el soporte y el acceso al metalink.

Pero fijaos en que ya se puede descargar Oracle DB líbremente sin soporte en las versiones a partir de la 10g. El siguiente paso lógico, es que se libere el código, seguramente al principio con una licéncia marciana creada por oracle y luego como pasó con java...

[#80 pawer13]

#34 Me parece que eres muy optimista, a mí meter Oracle y Open Source en la misma frase me sigue rechinando.

Si estuviese a favor del software libre, para empezar no denunciaría a Android por patentes de Java.

Y la versión gratuita de Oracle... bueno, cuando consideras que no puedes vender Oracle para pequeñas aplicaciones a las que les basta con MySQL porque no se puede competir con lo gratis, lo normal es que quieras copar ese mercado porque, si bien no te da dinero directamente, si que obtienes a un montón de gente "acostumbrada" a tus productos. Oracle quiere que todo el que necesite una base de datos acabe usando las suyas.
Es la misma razón que MS tiene para no preocuparse por los Windows piratas en los PCs de los particulares.

[#7 MycroftHolmes]

Nada nada, ya veo yo a todo el mundo migrando a DB2

[#6 Desactivado]

Lógico

[#13 BernatDesclot]

Que dios nos coja confesados...

[#24 emdi]

Pues yo me quedo con PostgreSQL. Por cierto que hace poco salió la v9, con muchas mejoras (replicación por ejemplo).

Pagina con información:
http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL

[#76 psql]

Actualmente no existe ninguna razon tecnica, de rendimiento y sobre todo de licencias para no elegir PostgreSQL sobre MySQL. Para los que esten interesados en aprender mas sobre PostgreSQL pasaros por PostgreSQL-es: http://www.postgresql.org.es/

Una vez que cambieis a PostgreSQL os aseguro que no volvereis atras.

[#85 condemore]

coge la palabra ORACLE, la das la vuelta y ya

[#14 Desactivado]

Personalmente estoy muy decepcionado con MYSQL; está a años luz (por detrás) de otros gestores de BBDD

[#19 kahun]

#14 Cada cosa es para lo que es, la escalabilidad que te aporta MySQL no la tienes con ningún otro.

[#30 AnTiX]

#19 A que es lo que llamais escalabilidad? Entiendo algo de mysql pero no se a que os referis

[#15 Desactivado]

Vale, esta es una noticia de aquellas que al principio abundaban en meneame, y ahora se ven, pero cada vez menos. Lamenteblamente ahora que hay menos no soy capaz de entender la mitad. Esto de la edad...

[#83 AlphaFreak]

#81 Cuando la forma natural de acceder a tus datos es mediante asociación de clave-valor, el SQL es más una molestia que otra cosa. Anima a hacer cosas que en un entorno de producción pesado son auténticas burradas. Por eso un fósil como IMS-DB sigue existiendo, se sigue usando y además IBM lo sigue desarrollando...

[#9 damian]

Un fork de Mysql yaaaaaaa....

[#17 Desactivado]

#9 Aqui mencionan unos cuantos: http://lwn.net/Articles/329626/

[#25 guillersk]

#9 Venga, empieza...
#20 http://lmgtfy.com/?q=mysql

[#39 MycroftHolmes]

Pequeña encuesta:
¿Cuál pensais que es el motor de BD más potente actualmente?

[#41 Desactivado]

#39 DB2

(Y que conste que no soy DBA de DB2 sino de Oracle)

[#43 MycroftHolmes]

#41 Yo opino como tú. Es que me llama la atención que cuando se hablan de motores de BD, nunca nadie habla de DB2

[#48 Desactivado]

#45 Todo eso también lo tienes en DB2, pero sin tanto bug como Oracle, que parece el mueble viejo de mi abuela de la carcoma que lleva dentro

#43 Será porque vale tanta pasta que es difícil permitírselo (generalmente es usado en AS400,ahora e-series o HOST, ahora z-series, o sea, sistemas mainframe con la BD integrada y que su lenguaje de scripting en lugar de shell es COBOL, sí sí, todavía vive el cabrón, en los AS400 y RPG y COBOL en los HOST). Un HOST vale muuuuuuuucha más pasta que una Oracle RAC Enterprise de 10 nodos todo licenciado.

Que alguien que tenga más idea que yo de los productos IBM me corrija si la he cagado en algo, que como ya he dicho no son mi especialidad.

[#51 MycroftHolmes]

#48 ¿Me permites una corrección? El lenguaje de scripting de un HOST es JCL (aquí un analista Host)
COBOL genera código objeto, así que no se puede considerar scripting

Por cierto, ¿os parece triste la consola, el vim o cualquier cosa para programar? El primer día que me enseñaron el ISPF/PDF, se me cayó el alma a los pies
http://www.tombrennansoftware.com/edit.gif

[#49 guillersk]

#43 DB2 es como el abuelo que está en una esquina, nadie le hace caso hasta que se le ocurre una idea genial.

[#44 cosmonauta]

#39 No hay respuesta. Depende de tus necesidades. ¿Que es mejor, un Ferrari o un tractor?

[#47 MycroftHolmes]

#44 Creo que cuando comparas Oracle-DB2 le pregunta es "¿Qué es mejor, un Ferrari o un Lamborghini?"

[#45 llamamepanete]

#39 Oracle: nivel del soporte transaccional, gestión vldb, como por todo el sistema de gestión: partición, replicación, recuperación, monitorización, como por toda la tecnología de aplicación que despliegan a partir de OAS. Vamos, a nivel Enterprise, me parece el entorno "más redondo".

[#54 marc0]

#39 Oracle Exadata Database Machine
http://www.oracle.com/us/products/database/database-machine-069034.html

[#56 MycroftHolmes]

#54 Corrígeme si me equivoco, pero si no he entendido mal, eso es una máquina física.

Yo me refería a "software". Si no me equivoco, eso lleva Oracle

[#63 marc0]

#56 Es hardware de Sun (o sea, de Oracle), con varios nodos en RAC de BD Oracle 11gR2 y, sobre todo, un software de cabina de disco optimizado para Oracle (Exadata)

[#68 MycroftHolmes]

#63 Vale, pero entonces Exadata no es propiamente dicho un motor de BD, es un "controlador de disco" brutal. Me da miedo mirar cuanto cuesta el aparatito ese

[#59 dac]

TheirSQL

[#20 tARQ]

Y para que sirve todo eso de lo que estáis hablando?¿ Vamos, de las bases de MySQL he oido hablar, pero nunca he sabido para que sirven, y del resto ni idea...

Alguna explicación por favor?¿

[#22 DavidHernandez]

#20 Todas las aplicaciones web (y no web, también) mínimamente avanzadas requieren una base de datos para almacenar información (como usuarios, contenido...). MySQL es una de las bases de datos más usadas y aunque es de código abierto y gratuíta, tiene otras versiones más "avanzadas" y un servicio de soporte, que es a lo que ahora le suben el precio.

El peligro que se corre es que a Oracle le deje de interesar mantener MySQL, como hacía Sun antes de la compra por parte de Oracle. Y con eso, se perdería una de las herramientas más usadas y necesarias.

[#31 tARQ]

#22 #26 Gracias!

#20 Googlear es facil, dar una explicación sencilla y resumida no tanto. Hay temas que si los buscas en google tienes cantidades ingentes de información, que si quieres tratar a fondo está muy bien, pero para tener unicamente una idea de lo que se está hablando es mejor que alguien que conoce el tema te cuente de que va. Yo buscaba eso, una explicación sencillita, no el funcionamiento y todos los detalles.

[#26 llamamepanete]

#20 MySQL, Postgresql, Oracle, etc, son bases de datos relacionales. Es decir, una tecnología para almacenar información en ellas. Usadas en cualquier lugar donde haga falta almacenar información: desde una página web, a una aplicación bancaria.

Las bases de datos relacionales tienen la propiedad de ordenarse en tablas, con campos, y además las tablas se pueden unir entre ellas, dando el valor de "relacional".

Por ejemplo, puedes tener la tabla "persona", con los campos "nombre, dni, edad, sistema_operativo" y la tabla "sistema operativo" con los campos "identificador, nombre, fabricante, precio". En estas tablas almacenaras personas y sistemas operativos. Además el campo sistema operativo de la tabla "persona", lo vas a relacionar con el campo "identificador" de la tabla "sistema operativo". De esta forma se puede ampliar la información e interconectarla, creando estructuras de datos "complejas" pero a partir de datos "sencillos".

La otra gran característica de los sistemas relacionales de bases de datos, es que te permiten consultar la información haciendo uso de un lenguaje denominado SQL, el cual tiene una potencia y una versatilidad bastante alta.

En el caso anterior, si quiero saber las personas que utilizan un sistema operativo fabricado por Microsoft, podría consultarlo mediante una sentencia SQL como la siguiente SELECT dni, nombre FROM persona WHERE sistema_operativo IN (SELECT identifador FROM sistemaoperativo WHERE fabricante= "Microsoft" )

[#33 pawer13]

#20 Añadiendo un poco más de "background": Oracle es una empresa cuyo principal producto es un sistema gestor de bases de datos (SGBD) potentísimo, el más usado del mundo, llamado también Oracle.
Oracle (la empresa) compró a Sun, la empresa dueña de, entre otras muchas cosas, MySQL, una alternativa libre y gratuita.

No tiene la capacidad de Oracle, pero en general tiene la potencia necesaria para la mayoría de las necesidades normales de una aplicación como Menéame (piensa en los miles de comentarios y sus votos, noticias y sus votos, los usuarios, su avatar y su karma...).

[#28 buly]

Se ha notado mucho el cambio que está haciendo Oracle con todo lo que respecta a Sun. Su política es muy distinta en todos los aspectos.

[#37 Desactivado]

Siempre nos quedará la versión OpenSource

[#42 Desactivado]

Esto se veía venir de lejos... No sé quién se sorprende.

[#53 Desactivado]

MySQL D.E.P. Tus amigos y tu viuda te recuerdan

[#62 hangla]

En breve haran lo mismo con JDE y con openoffice...

[#86 in0de]

¿De verdad estáis diciendo que DB2 es lo más potente que hay? Pero si hasta la versión 9.2 no soportaba un clúster activo-activo...

[#61 Desactivado]

Las versiones más baratas de MySQL estaban a un precio muy similar a las de Oracle Standard One. Ahora la cosa ya es descarada: Oracle es mucho más barato que MySQL.
Por cierto, hay que pagar si teneis la aplicación en internet o bién la vendeis y dicha aplicación no es opensource.
Y puestos a ver implicaciones, Facebook tendrá que pagar un poco más de pasta cada año a Oracle

[#66 MegaBoy]

#61

Que yo recuerde Facebook usaba CassandraDB.

[#69 Desactivado]

#66 Solo usa CassandraDB para cosas puntuales como búsquedas del correo de entrada. Para todo lo demás usan MySQL. Hay un bulo bastante extendido que hace creer que las bases de datos realacionales no escalan bien. Eso no es del todo cierto, las bases de datos relacionales son rapidísimas y si se despliegan como toca escalan de maravilla.

[#78 MegaBoy]

#69

Pues que decepción entonces. Parece que la alternativa que proclamaban los del NoSQL es más moda que otra cosa.

[#79 etnassoft]

#78 No hombre; el paradigma del NoSQL es perfectamente válido para otros escenarios. En realidad Facebook utiliza MySQL por dos razones básicas: el escalado y la necesidad de un modelo relacional estricto. NoSQL sin embargo es perfecto para la catalogación de documentos y todo aquello que no sea relacionable por naturaleza. Pero no, no es una 'moda', es el futuro: simplemente permite cosas que con una base de datos relacional no son posibles.

#69 Efectivamente, la escalabilidad de MySQL es fantástica y todo lo demás es un bulo. MySQL facilita el concepto de 'Scale Out' que consiste en utilizar distintas bases de datos replicándose unas con otras en lugar de mantener bases únicas de enorme coste. En este aspecto, MySQL aventaja a Postgre para grandes escenarios.

[#81 MegaBoy]

#79

No te contradigas, una cosa es que NoSQL pueda ser útil para ciertas tareas que con una base de datos relacional son más difíciles supuestamente (¿como no va a ser posible la catalogación de documentos con una base de datos relacional?) y otra muy distinta que sea el "futuro". ¿El futuro de que?. Nadie se va a instalar MongoDB para poner un blog.

Mi comentario viene a cuento de que se hablaba mucho de si NoSQL y tal (no conozco mucho el tema de base de datos fuera de programación sql muy estandard), y resulta que Facebook, por ejemplo, sólo lo usa en ciertos escenarios.

No me parece que eso sea el "futuro", sino otra herramienta más que la mayoría de la gente me parece que no va a usar mucho fuera de cosas muy específicas.

[#82 Desactivado]

Yo ataco tablas enormes bajo SQLite y va de narices. MySQL y Postgress me dan urticaria. Oracle, terror pánico.

[#87 MycroftHolmes]

#82 Define enorme...

[#16 Desactivado]

Como echo de menos a Sun Microsystems, esto no pasaba con ellos

[#57 cibeless]

#16 y yo tb, snif