Ir al contenido principal

Bases de Datos: Pasado (Oracle), Presente (MySQL), Futuro (¿db4o?)

En los últimos tiempos, tanto el gobierno británico como el alemán han apostado firmemente por invertir en Software Libre realizando progresivamente migraciones de sus sistemas propietarios.

En mi visita al Delivery Center de Accenture en Málaga, me aseguraban que las licencias de software propietario se habían encarecido un 25 por ciento en 2008. Costes en software propietario que ya eran bastante elevados en 2007.

Unos de los productos propietarios más ampliamente extendidos, incluso donde se ha apostado decididamente por Software libre, es el sistema de gestión de bases de datos Oracle. Sus virtudes principales son su robustez, su seguridad, y su soporte. Sus principales defectos son su lentitud, su complejidad y la gran cantidad de recursos que consume. A estos defectos habría que añadir su alto coste, tanto de licencias, como de mantenimiento, requiriendo personal formado específicamente para administrar este tipo de base de datos.

Creo que el fin de la época dorada de Oracle ha llegado. Actualmente hay una gran oferta de SGBDs "libres" que no tienen los defectos de Oracle, y cuyas virtudes se adaptan a lo que se necesita en la mayoría de sistemas de información que desarrollamos. Quizás no llegan a la potencia de Oracle, pero tampoco lo necesitamos, y además nos ofrecen otras prestaciones, como velocidad, o sencillez, que suponen un ahorro de costes extra.

Seguirá habiendo bases de datos Oracle, al igual que aun hay muchísimo trabajo para los programadores de Cobol, ya que hay aplicaciones críticas, cuya migración es difícil de asumir, pero pienso que no será adoptada en la mayoría de nuevos desarrollos.

Pienso que una buena solución es desarrollar con MySQL, sobretodo desde que fue comprada por Sun, y adquirió mayor madurez. Es fácil de instalar, de mantener, los requisitos del sistema para su funcionamiento son mínimos, es rápida, estable... "es todo lo que necesito" y es Software Libre. ¿Qué más se puede pedir?

La mayoría de desarrollos actuales para la Junta de Andalucía se están realizando con MySQL, aunque en Madeja (Marco de Desarrollo de la Junta de Andalucía) recomienden PostgreSQL (ya sabemos como es la política de desarrollo de las Administraciones Públicas...).

Al igual que MySQL es el presente, no creo que sea el futuro, o al menos no lo será el MySQL que conocemos actualmente. Es más, no tiene sentido que usemos el paradigma de programación Orientado a Objetos, y luego tengamos que realizar mapeos para convertir los objetos a registros, aunque para ello haya frameworks como Hibernate, que suponen una caja negra para el desarrollador en lo que a mapeo se refiere. Hibernate no deja de ser un "artificio", aunque cada vez ofrezca más funcionalidades, como el caché de segundo nivel, gestión de sesiones... pero que tienen un coste, sobretodo en rendimiento. Además, estas funcionalidades deben ser asumidas, en su mayor medida, por el SGBD.

En mi empresa hemos asumido desarrollos usando un SGBD orientado a objetos, db4o, que tiene un sistema de licenciamiento idéntico al de MySQL (licencia dual GPL/comercial). Los resultados han sido muy buenos. Es una base de datos ligera, sencilla y rápida, no usamos SQL sino operaciones sobre los objetos a persistir. Con db4o conseguimos no tener que duplicar el modelo de datos del dominio de la aplicación, es decir, no existe el diagrama E/R (todo son objetos). No tenemos que sacrificar rendimiento como ocurre cuando usamos un ORM. Lo podemos usar en una PDA, en un dispositivo con Android, en un sistema Windows, Linux... Es un sistema bastante novedoso, y aun tiene un largo camino por recorrer, pero, por ahí deben ir "los tiros".

Nota post post:
No sé como puede afectar esto a lo que he expuesto.

Comentarios

  1. Alejandro, yo creo que el futuro pasa, al menos en parte, por lo que son distributed key-value stores como Amazon SimpleDB, Apache CouchDB y Datastore de Google App Engine. El enlace habla de sus ventajas e inconvenientes.

    ResponderEliminar
  2. Precisamente en ese enlace están las claves que explican por qué, EMHO, no se terminarán imponiendo.

    En db40, un objeto se guarda en la base de datos de una manera tan sencilla como esta:

    store(objeto2);

    Y si por ejemplo, el objeto heredara del objeto1, el objeto1 se guardaría directamente. Es decir, con una simple operación, persisto la herencia, el polimorfismo, y mantengo integridad referencial.

    Si el objeto2, tiene como atributo un objeto3, este también se almacenaría, y la relación sería automática.

    Cuando extraigo el objeto de la BD, ya tengo el VO, no tengo que hacer ningún mapeo.

    Además es una BD ligera y rápida. En resumen, tiene casi todo lo bueno de la RDBMS, pero nada de lo malo, y no tiene los problemas de las key-value stores.

    ResponderEliminar

Publicar un comentario

Entradas populares de este blog

Métrica v3 vs Metodologías Ágiles

Métrica v3: Metodología de Planificación, Desarrollo y Mantenimiento de sistemas de información que propone el Ministerio de Administraciones Públicas.

Cualquier defensor de la técnicas, metodologías y herramienta ágiles sostendrá que Métrica v3 es un sistema demasiado pesado, tanto en su implementación, como en sus procesos de mantenimiento. Yo lo corroboraría, pero sin demonizarla.

Estoy acostumbrado a que en este mundo de la informática se creen auténticos "dogmas de fe", que acarrean sus propias "guerras religiosas". Algunos ejemplos podrían ser: Software privativo vs Software libre, Windows vs Linux, Web Services vs Rest, Oracle vs MySQL, Explorer vs Firefox, Apache vs IIS, Eclipse vs Netbeans, y así podríamos seguir con un largo etcétera. En vez de buscar la mejor solución, o soluciones universales, yo propongo realizar un intenso análisis, y respondernos ciertas preguntas. Por regla general, no hay una solución que valga "para todo". La pregunta que …

Scrum para Dummies

Introducción
Scrum es un marco de referencia para desarrollo ágil de productos. Esta metodología se puede aplicar a procesos de producción de distintos sectores, yo me centraré en el de Desarrollo de Software.

Desarrollo tradicional vs Desarrollo Ágil

Especialización vs Equipo Multidisciplinar
Fases vs Solapamiento
Requisitos detallados vs Visión del producto
Seguimiento del plan vs Adaptación a los cambios

Las metodologías tradicionales se ven como una carrera de relevos, en el que cada miembro es responsable de una fase, y hasta que no se termina una fase, es imposible comenzar las siguientes.
En cambio, las metodologías ágiles son más como un partido de Rugby, en el que el empuje conjunto del equipo es importantísimo para el éxito. De hecho, Scrum significa melé.

Ya comparé en un post anterior estos dos tipos de metodologías.

¿Por qué Scrum?
El cliente puede ver resultados desde el primer momento.
Se ahorra el tiempo que en las metodologías tradicionales se dedica en con…

¿Por qué Yii Framework?

En Soltel presumimos de tener una actitud innovadora, que nos obliga a probar las distintas tecnologías que van llegando al mercado, y que ajustándose a nuestro stack, puedan mejorar en algo nuestros desarrollos.

Una vez analizado el framework o librería, lo probamos en proyectos internos que nos permitan conocer con más detalle sus características. En este trabajo de campo es donde realmente se decide si es interesante o no añadir el framework a nuestro stack, y con ello ofrecerlo en los desarrollos que realizamos para nuestros clientes.

En este proceso, llevábamos bastante tiempo buscando un framework PHP que realmente aportara valor y se adecuara en tiempos de desarrollo, rendimiento y arquitectura a lo que necesitamos ofrecer en nuestros proyectos. Ya habíamos descartado frameworks como Prado, por ser bastante pesado y tener una arquitectura demasiado compleja.

Con Yii, sin embargo, nos hemos llevado una agradable sorpresa. Yii es un framework PHP, libre (licencia BSD), basado en pr…