database - que - ¿Por qué debería usar una base de datos basada en documentos en lugar de una base de datos relacional?
que es una base de datos no relacional (5)
CouchDB (desde su website )
Un servidor de base de datos documental, accesible a través de una API RESTful JSON. Generalmente, las bases de datos relacionales no son simplemente accedidas a través de servicios REST, sino que requieren una API SQL mucho más compleja. A menudo, estas API (JDBC, ODBC, etc.) son bastante complejas. REST es bastante simple.
Ad-hoc y sin esquema con un espacio de direcciones planas. Las bases de datos relacionales tienen un esquema complejo y fijo. Usted define tablas, columnas, índices, secuencias, vistas y otras cosas. Couch no requiere este nivel de planificación avanzada compleja, costosa y frágil.
Distribuido, con una replicación robusta e incremental con detección y gestión bidireccional de conflictos. Algunos productos comerciales de SQL ofrecen esto. Debido a la API SQL y los esquemas fijos, esto es complejo, difícil y costoso. Para Couch, parece simple y de bajo costo.
Query-able e indexable, que presenta un motor de informes orientado a tablas que utiliza Javascript como lenguaje de consulta. Lo mismo ocurre con las bases de datos SQL y relacionales. Nada nuevo aquí.
Asi que. ¿Por qué CouchDB?
- REST es más simple que JDBC u ODBC.
- No Schema es más simple que Schema.
- Distribuido de una manera que parece simple y económica.
¿Por qué debería usar una base de datos basada en documentos como CouchDB en lugar de usar una base de datos relacional? ¿Existen tipos típicos de aplicaciones o dominios donde la base de datos basada en documentos es más adecuada que la base de datos relacional?
El rápido desarrollo de aplicaciones me viene a la mente.
Cuando estoy constantemente evolucionando mi esquema, me siento frustrado constantemente por tener que mantener el esquema en MySQL / SQLite. Si bien no he hecho demasiado con CouchDB todavía, me gusta lo simple que es desarrollar el esquema durante el proceso de RAD.
Un caso en el que no desee utilizar una base de datos no relacional es cuando tiene muchas relaciones de muchos a muchos; Todavía tengo que entender cómo crear buenas funciones de MapReduce en torno a este tipo de relaciones, especialmente si necesita tener metadatos en la relación de unión. No estoy seguro, pero no creo que las funciones de CouchDB Map puedan invocar sus propias consultas en la base de datos, ya que eso podría causar bucles infinitos.
Para almacenar y servir estúpidamente a otros servidores de datos.
En las últimas semanas he estado jugando con una aplicación de lifestream que sondea mis feeds (delicious, flickr, github, twitter ...) y los almacena en couchdb. La belleza de couchdb es que me permite mantener los datos originales en su estructura original sin gastos generales. Agregué un campo de ''clase'' a cada documento, almacenando el servidor de origen y escribí una clase de renderizado de JavaScript para cada fuente.
Generalizando, siempre que su servidor se comunique con otro servidor, lo mejor es un almacenamiento sin esquema, ya que no tiene control sobre el esquema. Como beneficio adicional, couchdb utiliza los protocolos nativos de servidores y clientes: JSON para representación y HTTP REST para transporte.
Probablemente no deberías :-)
La segunda respuesta más obvia es que debe usarla si sus datos no son relacionales. Esto generalmente se manifiesta al no tener una manera fácil de describir sus datos como un conjunto de columnas. Un buen ejemplo es una base de datos donde usted realmente almacena documentos en papel, por ejemplo, escaneando el correo de la oficina. Los datos son el PDF escaneado y usted tiene algunos metadatos que siempre existen (escaneados, escaneados, tipo de documento) y muchos posibles campos de metadatos que existen en algún momento (número de cliente, número de proveedor, número de orden, mantener en el archivo hasta, Texto completo OCR, etc.). Por lo general, no sabe de antemano qué campos de metadatos agregará en los próximos dos años. Cosas como CouchDB funcionan mucho mejor para ese tipo de datos que las bases de datos relacionales.
También me encanta el hecho de que no necesito ninguna biblioteca de cliente para CouchDB, excepto un cliente HTTP, que actualmente está incluido en casi todos los lenguajes de programación.
La respuesta probablemente menos obvia: si no siente dolor al usar un RDBMS, quédese con él. Si siempre tiene que trabajar con su RDBMS para hacer su trabajo, una base de datos orientada a documentos podría valer la pena.
Para obtener una lista más elaborada, consulte esta publicación de Richard Jones .
Use una base de datos basada en documentos cuando no necesite almacenar datos en tablas con campos de tamaño uniforme para cada registro. En cambio, tiene la necesidad de almacenar cada registro como un documento que tiene ciertas características. Cualquier número de campos de cualquier longitud se puede agregar dinámicamente a un documento en cualquier momento sin la necesidad de "modificar la tabla" primero. Los campos basados en documentos también pueden contener múltiples piezas de datos.