Oracle, la empresa líder en bases de datos empresariales (y la #2 empresa de software del mundo detrás de Microsoft) acaba de darle una gran sorpresa al mercado al anunciar que ha decidido entrar al mercado de hardware, con servidores diseñados exclusivamente para ejecutar sus bases de datos a velocidades hasta 10 veces mas rápido que en hardware genérico.

La empresa sin embargo ha aclarado que no piensa ella misma fabricar estos equipos, sino que se ha asociado con terceros que los fabricarán por ellos. El primero de estas empresas asociadas es HP, con quien Oracle dice haber forjado una fuerte alianza en este territorio.

Noten sin embargo que estos no serán servidores de bajo costo o para pequeñas empresas, al menos no por el momento, ya que el primer modelo que sacarán al mercado será el HP Oracle Exadata Storage Server, el cual costará cerca de US$650,000 dólares, mas unos adicionales US$840,000 dólares por el software, y almacenará hasta 148 TeraBytes de datos.

Algo me dice que aunque esto encontrará su nicho en grandes empresas (que de todas maneras es el fuerte de Oracle), que el no haber pensado en modelos mas asequibles (digamos en el rango de US$10,000 dólares) afectará adversamente a la empresa en su lucha contra su nuevo gran enemigo, la base de datos de Código Libre (Open Source) MySQL, que cada vez se torna mas poderosa, es gratuita, bastante rápida (mas rápida que Oracle en algunos escenarios), y tiene mucho soporte por lo usuarios de Linux.

Por ahora MySQL está formando su mercado en pequeñas y medianas empresas, pero vendrá el tiempo en donde muchas de estas grandes empresas se preguntarán porqué gastan millones de dólares al año en Oracle, cuando pueden obtener algo similar con MySQL a un costo insignificante.

Es cierto que hay escenarios para los cuales Oracle es mucho mas apropiado, pero también es cierto que cada año MySQL se torna mas potente, aprende nuevas funcionalidades, y se hace mas rápida, mas simple de administrar (con decenas de herramientas gráficas de todo tipo), mas ligera y menos demandante en los requerimientos de hardware que Oracle.

No lo duden que se avecina una guerra entre estas dos bases de datos, aunque en general, a corto plazo, creo que esta movida por parte de Oracle es acertada, ya que simplifica el proceso de compra, y entrega un producto preconfigurado, probado, listo para arrancar, de bajo riesgo y de alto rendimiento.

Nota relacionada: Una razón por la cual a muchas empresas se les hará difícil cambiar de Oracle a otra base de datos es el hecho de que Oracle ha hecho bastante fácil que los programadores cometan el grave error de programar mucha de la lógica de sus aplicaciones con el lenguaje de programación propietario de Oracle, que se ejecuta dentro de la base de datos.

Esto tiene como efecto que no sea tan sencillo como decir "cambiemos la base de datos y corrijamos las pequeñas diferencias de SQL entre las dos bases de datos y ya estamos listos." La realidad es que debido a la vagancia o ignorancia de los programadores que han utilizado estas herramientas de Oracle para crear millones de lineas de código de Procedimientos Almacenados, en vez de delegar muchas de esas funcionalidades a un servidor de aplicaciones, se hará bastante difícil migrar esas aplicaciones a otro entorno.

Es tan grave el asunto que muchas de estas aplicaciones tendrán que rehacerse casi desde cero, en vez de migrarse, esto al uso abusivo de Procedimientos Almacenados, los cuales tienen un uso útil (en acelerar funciones críticas de acceso a la base de datos), pero que los programadores han utilizado de manera ignorante para crear todo tipo de lógica de programación.

Así que un consejo (que no recibirán de ningún fabricante ni fanático de bases de datos, pero sí de cualquier arquitecto de aplicaciones con experiencia), es que traten de mantener el uso de Procedimientos Almacenados a lo mas mínimo, y de la manera mas atomizada y documentada posible, de modo que si en un futuro por cualquier motivo hay que cambiar de bases de datos, solo haya que hacer algunas modificaciones superficiales.

Otro consejo es que hoy día, con los precios de los servidores por el suelo, si tienes una operación de SQL que tome mucho tiempo, es mejor comprar un par de servidores y procesar los datos de manera distribuida en ellos a nivel de aplicación, que tener que escribir centenares o lineas de código en la base de datos, o de tener que comprar un motor nuevo (o nueva versión) de base de datos, que hoy día puede costar varias veces mas que un servidor físico con Linux o Windows.

Fuente de la noticia

Otra fuente

autor: josé elías