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