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.
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.
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.
ResponderEliminarPrecisamente en ese enlace están las claves que explican por qué, EMHO, no se terminarán imponiendo.
ResponderEliminarEn 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.