database - relacionales - usar mongodb y mysql

Ventajas/inconvenientes de las bases de datos basadas en documentos vs. bases de datos relacionales (6)

He estado tratando de ver si puedo cumplir algunos requisitos con una base de datos basada en documentos, en este caso, CouchDB. Dos requisitos genéricos:

CRUD de entidades con algunos campos que tienen un índice único en él
aplicación web de comercio electrónico como eBay ( mejor descripción aquí ).

Y estoy empezando a pensar que una base de datos basada en documentos no es la mejor opción para abordar estos requisitos. Además, no puedo imaginar un uso para una base de datos basada en documentos (tal vez mi imaginación es demasiado limitada).

¿Puede explicarme si estoy pidiendo peras de un olmo cuando trato de utilizar una base de datos orientada a documentos para estos requisitos?

¿Hay una necesidad de normalizar los datos?

Sí: usa relacional.
No: use el documento.

Debe pensar en cómo enfoca la aplicación de una manera orientada a documentos. Si simplemente intenta replicar cómo modelaría el problema en un RDBMS, fallará. También hay diferentes intercambios que podría querer hacer. ([ed: no estoy seguro de cómo se relaciona esto con el argumento, pero:] Recuerde que el diseño de CouchDB supone que tendrá un clúster activo de muchos nodos que podrían fallar en cualquier momento. ¿Cómo va a manejar su aplicación uno de los nodos de la base de datos que desaparece? ¿bajo ello?)

Una forma de pensarlo es imaginar que no tienes computadoras, solo documentos en papel. ¿Cómo crearías un proceso de negocios eficiente utilizando trozos de papel que se pasen? ¿Cómo puedes evitar los cuellos de botella? ¿Qué pasa si algo sale mal?

Otro ángulo en el que deberías pensar es la consistencia final, donde eventualmente entrarás en un estado consistente, pero es posible que seas inconsistente por un período de tiempo. Esto es un anatema en tierra RDBMS, pero extremadamente común en el mundo real. El ejemplo de transacción canónica es la transferencia de dinero desde cuentas bancarias. ¿Cómo sucede esto realmente en el mundo real - a través de transacciones atómicas individuales o a través de diferentes bancos que emiten avisos de crédito y débito entre ellos? ¿Qué pasa cuando escribes un cheque?

Así que veamos tus ejemplos:

CRUD de entidades con algunos campos con índice único en él.

Si entiendo esto correctamente en términos de CouchDB, ¿desea tener una colección de documentos donde se garantice que algún valor con nombre sea único en todos esos documentos? Ese caso no es generalmente compatible porque los documentos pueden crearse en diferentes réplicas.

Entonces tenemos que mirar el problema del mundo real y ver si podemos modelar eso. ¿Realmente los necesitas para ser únicos? ¿Puede su aplicación manejar múltiples documentos con el mismo valor? ¿Necesita asignar un identificador único? ¿Puedes hacer eso de manera determinista? Un escenario común donde esto es necesario es cuando necesita un identificador secuencial único. Esto es difícil de resolver en un entorno replicado. De hecho, si se requiere que la identificación única sea estrictamente secuencial con respecto al tiempo creado, es imposible si necesita la identificación de inmediato. Necesitas relajar al menos una de esas restricciones.

aplicación web de comercio electrónico como eBay

No estoy seguro de qué agregar aquí, ya que el último comentario que hizo en esa publicación fue decir "¡Muy útil! Gracias". ¿Hubo algo que faltaba en el enfoque descrito allí que todavía te está causando un problema? Pensé que la respuesta del Sr. Kurt estaba bastante completa y agregué una pequeña mejora que reduciría la contención.

Estoy en el mismo bote, me encanta couchdb en este momento, y creo que todo el estilo funcional es genial. Pero cuando exactamente empezamos a usarlos en Ernest para aplicaciones. Quiero decir, sí, todos podemos comenzar a desarrollar aplicaciones de forma extremadamente rápida, libres de cruces, con todos esos desagradables problemas sobre la forma normal que se dejan en el camino y sin usar esquemas. Pero, para acuñar una frase "estamos parados sobre los hombros de gigantes". Hay una buena razón para usar RDBMS y para normalizar y usar esquemas. Mi vieja cabeza de oráculo se tambalea al pensar en datos sin forma.

Mi principal factor sorpresa en couchdb es la replicación y el sistema de control de versiones trabajando en tándem.

He estado trabajando duro en mi cerebro durante el último mes tratando de asimilar los mecanismos de almacenamiento de couchdb, aparentemente usa árboles B pero no almacena datos basados en la forma normal. ¿Esto significa que es realmente realmente inteligente y se da cuenta de que los bits de datos se replican, así que vamos a hacer un puntero a esta entrada en el árbol B?

Hasta ahora estoy pensando en documentos xml, archivos de configuración, archivos de recursos transmitidos a bases64 strings.

Pero, ¿usaría couchdb para datos estructurales? No lo sé, cualquier ayuda muy apreciada en esto.

Puede ser útil para almacenar datos RDF o incluso texto de forma libre.

Los DB basados en documentos son los mejores para almacenar, bueno, documentos. Lotus Notes es una implementación común y el correo electrónico de Notes es un ejemplo. Para lo que está describiendo, eCommerce, CRUD, etc., los DB reales están mejor diseñados para el almacenamiento y la recuperación de elementos / elementos de datos indexados (a diferencia de los documentos).

Re CRUD: todo el paradigma REST se asigna directamente a CRUD (o viceversa). Entonces, si sabe que puede modelar sus requisitos con recursos (identificables a través de URI) y un conjunto básico de operaciones (es decir, CRUD), puede estar muy cerca de un sistema basado en REST, que proporcionan bastantes sistemas orientados a documentos De la caja.

Una posibilidad es tener una base de datos relacional principal que almacene definiciones de elementos que puedan ser recuperados por sus ID, y una base de datos de documentos para las descripciones y / o especificaciones de esos artículos. Por ejemplo, podría tener una base de datos relacional con una tabla de productos con los siguientes campos:

ID del Producto
Descripción
Precio unitario
Tamaño del lote
Presupuesto

Y ese campo Especificaciones en realidad contendría una referencia a un documento con las especificaciones técnicas del producto. De esta manera, tienes lo mejor de ambos mundos.