Acabo de comenzar con bases de datos no relacionales, y todavía estoy tratando de entenderlo y descubrir cuál sería el mejor modelo. Y solo puedo hablar por CouchDB.
Aún así, tengo algunas conclusiones preliminares:
¿Ha creado diseños alternativos que funcionen mucho mejor en el mundo no relacional?
El enfoque del diseño cambia: el diseño del modelo de documento (correspondiente a las tablas de la base de datos) se vuelve casi irrelevante, mientras que todo depende del diseño de las vistas (correspondiente a las consultas).
La base de datos de documentos cambia las complejidades: SQL tiene datos inflexibles y consultas flexibles, las bases de datos de documentos son al revés.
El modelo CouchDB es una colección de "documentos JSON" (básicamente tablas hash anidadas). Cada documento tiene una identificación única y se puede recuperar trivialmente por identificación. Para cualquier otra consulta, escribe "vistas", que se denominan conjuntos de funciones de mapa / reducción. Las vistas devuelven un conjunto de resultados como una lista de pares clave / valor.
El truco es que no consulta la base de datos en el sentido de que consulta una base de datos SQL: los resultados de ejecutar las funciones de vista se almacenan en un índice y solo se puede consultar el índice. (Como "obtener todo", "obtener clave" o "obtener rango de claves").
La analogía más cercana en el mundo de SQL sería si solo pudiera consultar la base de datos utilizando procedimientos almacenados: cada consulta que desee admitir debe estar predefinida.
El diseño de los documentos es enormemente flexible. He encontrado solo dos restricciones:
- Mantenga los datos relacionados juntos en el mismo documento, ya que no hay nada que corresponda a una combinación.
- No haga que los documentos sean tan grandes que se actualicen con demasiada frecuencia (como poner todas las ventas de la empresa durante el año en el mismo documento), ya que cada actualización de documento desencadena una reindexación.
Pero todo depende del diseño de las vistas.
Los diseños alternativos que he encontrado que funcionan mejor con CouchDB que con cualquier base de datos SQL están a nivel de sistema en lugar de a nivel de almacenamiento. Si tiene algunos datos y desea servirlos en una página web, la complejidad del sistema total se reduce al menos en un 50%:
- sin diseñar tablas de base de datos (problema menor)
- sin capa intermedia ODBC / JDBC, todas las consultas y transacciones a través de http (problema moderado)
- mapeo simple de DB a objeto desde JSON, que es casi trivial en comparación con el mismo en SQL (¡importante!)
- potencialmente puede omitir todo el servidor de aplicaciones, ya que puede diseñar sus documentos para que sean recuperados directamente por el navegador usando AJAX y agregar un poco de pulido de JavaScript antes de que se muestren como HTML. (¡¡ENORME!!)
Para las aplicaciones web normales, las bases de datos basadas en documentos / JSON son una gran ventaja, y los inconvenientes de las consultas menos flexibles y algún código adicional para la validación de datos parecen un pequeño precio a pagar.
¿Te has golpeado la cabeza contra algo que parece imposible?
Aún no. Map / reduce como un medio de consultar una base de datos no es familiar y requiere mucho más pensamiento que escribir SQL. Hay una cantidad bastante pequeña de primitivas, por lo que obtener los resultados que necesita es principalmente una cuestión de ser creativo con la forma en que especifica las claves.
Existe una limitación en el sentido de que las consultas no pueden examinar dos o más documentos al mismo tiempo: no hay combinaciones ni otros tipos de relaciones de varios documentos, pero hasta ahora nada ha sido insuperable.
Como limitación de ejemplo, los recuentos y las sumas son fáciles, pero los promedios no se pueden calcular mediante una vista / consulta de CouchDB. Solución: devuelva la suma y cuente por separado y calcule el promedio del cliente.
¿Ha cerrado la brecha con algún patrón de diseño, por ejemplo, para traducir de uno a otro?
No estoy seguro de que sea factible. Es más un rediseño completo, como traducir un programa de estilo funcional a un estilo orientado a objetos. En general, hay muchos menos tipos de documentos que tablas SQL y más datos en cada documento.
Una forma de pensarlo es buscar en su SQL inserciones y consultas comunes: ¿qué tablas y columnas se actualizan cuando un cliente realiza un pedido, por ejemplo? ¿Y cuáles para los informes de ventas mensuales? Esa información probablemente debería ir en el mismo documento.
Es decir: Un documento para Pedido, que contiene ID de cliente e ID de producto, con campos replicados según sea necesario para simplificar las consultas. Cualquier cosa dentro de un documento se puede consultar fácilmente, cualquier cosa que requiera una referencia cruzada entre, por ejemplo, el Pedido y el Cliente, debe hacerlo el cliente. Entonces, si desea un informe sobre las ventas por región, probablemente debería poner un código de región en el pedido.
¿Incluso hace modelos de datos explícitos ahora (por ejemplo, en UML)?
Lo siento, nunca hice mucho UML antes de documentar DBs :)
Pero necesita algún tipo de modelo que diga qué campos pertenecen a qué documentos y qué tipo de valores contienen. Tanto para su propia referencia más adelante como para asegurarse de que todos los usuarios de la base de datos conozcan las convenciones. Dado que ya no obtiene un error si almacena una fecha en un campo de texto, por ejemplo, y cualquiera puede agregar o eliminar cualquier campo que desee, necesita tanto el código de validación como las convenciones para tomar el relevo. Especialmente si trabaja con recursos externos.
¿Echa de menos alguno de los principales servicios adicionales que ofrecen los RDBMS?
¡No! Pero mi experiencia es desarrollador de aplicaciones web, tratamos con bases de datos solo en la medida en que debemos :)
Una empresa para la que solía trabajar creó un producto (una aplicación web) que fue diseñado para ejecutarse en bases de datos SQL de múltiples proveedores, y los "servicios adicionales" son tan diferentes de una base de datos a otra que tuvieron que implementarse por separado para cada base de datos. Así que nos costó menos sacar la funcionalidad del RDBMS. Esto incluso se extendió a la búsqueda de texto completo.
Entonces, lo que sea que estoy renunciando es algo que nunca tuve en primer lugar. Obviamente, su experiencia puede diferir.
Una advertencia: en lo que estoy trabajando ahora es en una aplicación web para datos financieros, cotizaciones de acciones y similares. Esta es una muy buena combinación para una base de datos de documentos, desde mi punto de vista, obtengo todos los beneficios de una base de datos (persistencia y consultas) sin ninguna molestia.
Pero estos datos son bastante independientes entre sí, no existen consultas relacionales complejas. Obtenga las últimas cotizaciones por ticker, obtenga cotizaciones por ticker y rango de fechas, obtenga metainformación de la empresa, eso es prácticamente todo. Otro ejemplo que vi fue una aplicación de blog, y los blogs tampoco se caracterizan por esquemas de bases de datos enormemente complicados.
Lo que estoy tratando de decir es que todas las aplicaciones exitosas de bases de datos de documentos que conozco han sido con datos que no tenían muchas interrelaciones en primer lugar: documentos (como en la búsqueda de Google), publicaciones de blogs, artículos de noticias, datos financieros .
Espero que haya conjuntos de datos que se asignen mejor a SQL que al modelo de documento, así que imagino que SQL sobrevivirá.
Pero para aquellos de nosotros que solo queremos una forma sencilla de almacenar y recuperar datos, y sospecho que somos muchos, las bases de datos de documentos (como en CouchDB) son una bendición.