Hace ya unos años que los programadores hablaban de un "Invierno Nuclear" en los lenguajes de programación, provocado por Java. Había una sensación generalizada de que todo convergía al modelo de Java (y C# era visto como una burda copia), que la creatividad en los lenguajes de programación  había desaparecido. Esta sensación está cambiando en la actualidad, pero quizás esté ocurriendo el comienzo de algo más importante: el pensar y analizar profundamente a las bases de datos.

Cuando comencé en la profesión de desarrollar software, trabajé con varias personas que evangelizaban a las bases de datos relacionados. Me los crucé en el mundo de la orientación a objetos. Muchas personas en esa época esperaban que las bases de datos orientadas a objetos se conviertan en el próximo paso revolucionario de las bases de datos. Como hoy ya sabemos, esto no ocurrió. Las bases de datos relacionales están tan profundamente embebidas que la mayoría de los proyectos asume el uso de bases de datos relaciones desde el inicio.

La semana pasada en la QCon hubo una serie de discusiones importantes que cuestionaban esta asunsión. Uno de los que más me interesó fue la charla de Tim Bray, quien hizo un repaso a través de varios aspectos de la gestión de datos. En el transcurso, aprovechó para enumerar varios proyectos interesantes:

• Drizzle es una forma de base de datos relacional, pero sin la mayoría de la maquinaria de los productos relacionales modernos. Es como una RISC RDBMS - soporta sólo las partes fundamentales del conjuto de características relacional.
• Couch DB se basa en un modelo de pares clave-valor distribuidos. Aunque es estricticamente un modelo muy simple (nada más que un hashmap en realidad), este tipo de enfoque se volvió muy popular para los sitios web con alto volumen de tráfico.
• Gemstone es una base de datos de objetos, y la combinación Gemstone-Smalltalk es muy poderosa en el desarrollo (y superior a la mayoría de sus sucesores). Gemstone es un jugador menor en el mercado, pero podría llegar a atraer más atención a través de Maglev, un proyecto para llevar este enfoque (la fusión de base de datos y máquina virtual) al mundo de Ruby.

La pregunta natural que surge sobre estos productos es porqué van a tener éxito cuando las bases de datos de objetos fallaron. ¿Qué cambió en el mundo para que las bases relacioneles pierdan terreno? Hay muchas hipótesis sobre porqué las bases relacionales son tan dominantes - mi opinión es que la importancia actual de las bases relacionales no es por su rol en la gestión de datos, sino por su rol en la integración.

Para muchas organizaciones de hoy en día, el principal patrón de integración es el de Integración por Base de Datos Compartida, en donde se integran múltiples aplicaciones mediante el uso compartido de una única base de datos. Cuando se tiene estas Bases de Integración, es importante que todas las aplicaciones puedan recuperar facilmente todos los datos compartidos, de ahí la importancia del rol de SQL. El rol de SQL como un lenguaje de consultas casi-estándard fue central para el predominio de las bases de datos.

El espacio de las bases de datos hoy se ve en debate por la presencia de varias alternativas de integración - en particular, la emergencia de los servicios wegb. Bajo distintos enfoques, hay un movimiento creciente para que las aplicaciones hablen entre ellas a través de documentos de texto (en general, XML) sobre HTTP. La web, tanto en internet como intranet, es un modo de integración incluso más prevalente que el SQL. Esto es algo bueno, ya que nunca me gustó el enfoque de múltiples aplicaciones acopladas fuertemente a través de una base de datos compartida - es la que más rompe el concepto de encapsulación.

Si cambiamos el protocolo de integración de SQL hacia HTTP, significa que se pueden cambiar las bases de datos de ser Bases de Integración a convertirse en Bases de Aplicación. Este cambio es profundo. Como primer paso permite un enfoque mucho más simple para el mapeo objeto-relacional, como el tomado por Ruby on Rails. Pero más aún, rompe con la necesidad de los modelos de datos relacionales. Al integrar via HTTP, deja de importar cómo una aplicación almacena sus datos, lo que a su vez significa que una aplicación puede elegir el modelo de datos que tiene más sentido para sus necesidades.

No creo que esto signifique el fin de las bases de datos relacionales - de hecho son la elección apropiada para muchas situaciones. Pero si significa que ahora los desarrolladores de aplicaciones deben comenzar a pensar cuál es la elección apropiada para sus necesidades. A medida que los proyectos no-relacionales crecen y maduran, más espacio va a existir para otras opciones

Basado en Martin Fowler: Database thaw.