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 …

¿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…

Gestor documental Alfresco vs sistema de archivos

En muchas ocasiones, antes incluso de tener que justificar por qué implantar Alfresco y no otro gestor documental, debemos argumentar a nuestros clientes qué ventajas les aporta usar Alfresco sobre su habitual forma de trabajo, que es, casi siempre, utilizar carpetas en el sistema de archivos de un servidor.

Estos son los argumentos que solemos dar en Soltel:

- Facilidad de explotar la documentación desde otras aplicaciones. Alfresco tiene una API potente a través de la cuál podemos sacar el máximo partido de éste cuando lo integramos con otras aplicaciones.
- Acceso a la información desde cualquier lugar, a cualquier hora y desde múltiples dispositivos (PC, Dispositivos móviles, Tablets, etc.). Toda la información que necesitamos se encuentra en la red y debidamente protegida. Solo necesitamos una conexión a internet. Ya no hacen falta ni VPNs, ni escritorios remotos.
– No es necesario el acceso al sistema operativo anfitrión, evitando que usuarios puedan visualizar aplicativos o informa…