У меня есть вопрос, на который я уже некоторое время пытаюсь ответить, но не могу понять:
Как вы разрабатываете или разделяете документы CouchDB?
Возьмем, к примеру, сообщение в блоге.
Полу "реляционный" способ сделать это - создать несколько объектов:
- Почта
- пользователь
- Комментарий
- Тег
- отрывок
В этом есть большой смысл. Но я пытаюсь использовать couchdb (по всем причинам, что это здорово) для моделирования того же самого, и это было чрезвычайно сложно.
Большинство сообщений в блогах дают простой пример того, как это сделать. Они в основном разделяют его одинаково, но говорят, что вы можете добавлять «произвольные» свойства к каждому документу, что определенно приятно. Итак, у вас будет что-то вроде этого в CouchDB:
- Публикация (с тегами и фрагментами «псевдо» моделей в документе)
- Комментарий
- пользователь
Некоторые люди даже сказали бы, что вы можете добавить туда комментарий и пользователя, чтобы у вас было следующее:
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, чтобы использовать их в моделях комментариев, то же самое с пользователями и тегами.
Но потом я думаю: «Почему бы просто не поместить весь мой сайт в один документ?»:
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"
...
}
}
}
}
}
Вы можете легко сделать просмотры, чтобы найти то, что вам нужно.
Тогда у меня возникает вопрос, как вы определяете, когда разделить документ на более мелкие документы, или когда установить «ОТНОШЕНИЯ» между документами?
Я думаю, что было бы намного более «объектно-ориентированным», и было бы легче сопоставить объекты-значения, если бы они были разделены следующим образом:
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
}
}
... но затем он начинает больше походить на реляционную базу данных. И часто я наследую что-то похожее на «весь сайт в документе», поэтому сложнее смоделировать это с помощью отношений.
Я много читал о том, как и когда использовать реляционные базы данных и базы данных документов, так что это не главная проблема. Мне больше просто интересно, какое хорошее правило / принцип следует применять при моделировании данных в CouchDB.
Другой пример - файлы / данные XML. Некоторые данные XML имеют более 10 уровней вложенности, и я хотел бы визуализировать это с помощью того же клиента (например, Ajax on Rails или Flex), который я бы использовал для рендеринга JSON из ActiveRecord, CouchRest или любого другого Object Relational Mapper. Иногда я получаю огромные XML-файлы, которые представляют собой всю структуру сайта, например, приведенный ниже, и мне нужно сопоставить их с объектами значений для использования в моем приложении Rails, чтобы мне не приходилось писать другой способ сериализации / десериализации данных. :
<pages>
<page>
<subPages>
<subPage>
<images>
<image>
<url/>
</image>
</images>
</subPage>
</subPages>
</page>
</pages>
Итак, общие вопросы CouchDB:
- Какие правила / принципы вы используете для разделения ваших документов (отношений и т. Д.)?
- Можно ли поместить весь сайт в один документ?
- Если да, то как вы обрабатываете сериализацию / десериализацию документов с произвольными уровнями глубины (например, большой пример json выше или пример xml)?
- Или вы не превращаете их в виртуальные организации, а просто решаете, что «они слишком вложены в объектно-реляционную карту, поэтому я просто буду обращаться к ним, используя необработанные методы XML / JSON»?
Большое спасибо за вашу помощь, мне было трудно сказать, как разделить ваши данные с помощью CouchDB: «Вот как я должен это делать с этого момента». Надеюсь скоро приеду.
Я изучил следующие сайты / проекты.
- Иерархические данные в CouchDB
- CouchDB Вики
- Диван - приложение CouchDB
- CouchDB - полное руководство
- Скринкаст PeepCode CouchDB
- CouchRest
- CouchDB README
... но они до сих пор не ответили на этот вопрос.