Tengo una pregunta que he intentado responder durante algún tiempo pero no puedo resolver:
¿Cómo diseña o divide los documentos de CouchDB?
Tome una publicación de blog, por ejemplo.
La forma semi "relacional" de hacerlo sería crear algunos objetos:
- Enviar
- Usuario
- Comentario
- Etiqueta
- Retazo
Esto tiene mucho sentido. Pero estoy tratando de usar couchdb (por todas las razones por las que es genial) para modelar lo mismo y ha sido extremadamente difícil.
La mayoría de las publicaciones de blogs te ofrecen un ejemplo sencillo de cómo hacer esto. Básicamente lo dividen de la misma manera, pero dicen que puede agregar propiedades 'arbitrarias' a cada documento, lo que definitivamente es bueno. Entonces tendrías algo como esto en CouchDB:
- Publicar (con etiquetas y fragmentos "pseudo" modelos en el documento)
- Comentario
- Usuario
Algunas personas incluso dirían que podría lanzar el comentario y el usuario allí, por lo que tendría esto:
post {
id: 123412804910820
title: "My Post"
body: "Lots of Content"
html: "<p>Lots of Content</p>"
author: {
name: "Lance"
age: "23"
}
tags: ["sample", "post"]
comments {
comment {
id: 93930414809
body: "Interesting Post"
}
comment {
id: 19018301989
body: "I agree"
}
}
}
Eso se ve muy bien y es fácil de entender. También entiendo cómo puede escribir vistas que extraigan solo los comentarios de todos sus documentos de publicación, para incluirlos en modelos de comentarios, lo mismo con los usuarios y las etiquetas.
Pero luego pienso, "¿por qué no poner todo mi sitio en un solo documento?":
site {
domain: "www.blog.com"
owner: "me"
pages {
page {
title: "Blog"
posts {
post {
id: 123412804910820
title: "My Post"
body: "Lots of Content"
html: "<p>Lots of Content</p>"
author: {
name: "Lance"
age: "23"
}
tags: ["sample", "post"]
comments {
comment {
id: 93930414809
body: "Interesting Post"
}
comment {
id: 19018301989
body: "I agree"
}
}
}
post {
id: 18091890192984
title: "Second Post"
...
}
}
}
}
}
Podrías crear vistas fácilmente para encontrar lo que querías con eso.
Entonces, la pregunta que tengo es, ¿cómo se determina cuándo dividir el documento en documentos más pequeños o cuándo hacer "RELACIONES" entre los documentos?
Creo que sería mucho más "Orientado a objetos" y más fácil de asignar a Objetos de valor, si se dividiera así:
posts {
post {
id: 123412804910820
title: "My Post"
body: "Lots of Content"
html: "<p>Lots of Content</p>"
author_id: "Lance1231"
tags: ["sample", "post"]
}
}
authors {
author {
id: "Lance1231"
name: "Lance"
age: "23"
}
}
comments {
comment {
id: "comment1"
body: "Interesting Post"
post_id: 123412804910820
}
comment {
id: "comment2"
body: "I agree"
post_id: 123412804910820
}
}
... pero luego comienza a parecerse más a una base de datos relacional. Y muchas veces heredo algo que se parece al "sitio completo en un documento", por lo que es más difícil modelarlo con relaciones.
He leído muchas cosas sobre cómo / cuándo usar bases de datos relacionales frente a bases de datos de documentos, así que ese no es el problema principal aquí. Me pregunto más, ¿cuál es una buena regla / principio para aplicar al modelar datos en CouchDB?
Otro ejemplo es con archivos / datos XML. Algunos datos XML tienen anidación de más de 10 niveles de profundidad, y me gustaría visualizar eso usando el mismo cliente (Ajax on Rails, por ejemplo, o Flex) que haría para renderizar JSON desde ActiveRecord, CouchRest o cualquier otro Object Relational Mapper. A veces obtengo archivos XML enormes que son la estructura completa del sitio, como el que se muestra a continuación, y necesito asignarlos a Value Objects para usarlos en mi aplicación Rails para no tener que escribir otra forma de serializar / deserializar datos :
<pages>
<page>
<subPages>
<subPage>
<images>
<image>
<url/>
</image>
</images>
</subPage>
</subPages>
</page>
</pages>
Entonces, las preguntas generales de CouchDB son:
- ¿Qué reglas / principios utiliza para dividir sus documentos (relaciones, etc.)?
- ¿Está bien poner todo el sitio en un solo documento?
- Si es así, ¿cómo maneja la serialización / deserialización de documentos con niveles de profundidad arbitrarios (como el ejemplo grande de json anterior o el ejemplo xml)?
- ¿O no los convierte en VO, simplemente decide "estos están demasiado anidados en Object-Relational Map, así que accederé a ellos usando métodos XML / JSON sin procesar"?
Muchas gracias por su ayuda, el tema de cómo dividir sus datos con CouchDB ha sido difícil para mí decir "así es como debo hacerlo de ahora en adelante". Espero llegar pronto.
He estudiado los siguientes sitios / proyectos.
- Datos jerárquicos en CouchDB
- Wiki CouchDB
- Sofá - Aplicación CouchDB
- CouchDB La guía definitiva
- PeepCode CouchDB Screencast
- Sofá
- Léame de CouchDB
... pero aún no han respondido a esta pregunta.