Я предлагаю вам хранить различные части (пользователи, вопросы, ответы, комментарии, теги, голоса) как отдельные документы в одной базе данных.
Нет. Не храните их в отдельных базах данных. Вы потеряете силу представлений и будете вынуждены делать экспоненциальное количество HTTP-запросов для сбора данных.
-
Проверьте http://www.cmlenz.net/archives/2007/10/couchdb-joins. Это действительно проливает свет на эту тему для меня. Кредит Коста для обмена ссылкой в другой вопрос .
Несмотря на то, что в статье используется вездесущий пример блога, я считаю, что подход № 2 с «View Collation» - это то, что вам нужно.
Документы, являющиеся потомками другого документа, будут связаны атрибутом родителя "_id". Кроме того, вы дадите своим документам атрибут «тип» для их упорядочения при возврате в виде. Например:
function(doc) {
if (doc.type == "post") {
map([doc._id, 0], doc);
} else if (doc.type == "comment") {
map([doc.post, 1], doc);
}
}
То, что вы вернули, это:
{
"total_rows": 5, "offset": 0, "rows": [{
"id": "myslug",
"key": ["myslug", 0],
"value": {...}
}, {
"id": "ABCDEF",
"key": ["myslug", 1],
"value": {...}
}, {
"id": "DEFABC",
"key": ["myslug", 1],
"value": {...}
}, {
"id": "other_slug",
"key": ["other_slug", 0],
"value": {...}
}, {
"id": "CDEFAB",
"key": ["other_slug", 1],
"value": {...}
}]
}
Теперь все данные, родительские и дочерние элементы возвращены в одном HTTP-запросе. Кроме того, вы можете использовать CRUD для этих документов напрямую через REST API. Что именно то, что вы хотите, на мой взгляд.
Вы можете применить тот же подход ко всему, что имеет отношение один-ко-многим или многие-к-одному.
Надеюсь, это поможет!