2010-11-22 2 views
4

Я ищу хорошие примеры/методы хранения и структурирования данных в CouchDB.Примеры структурирования CouchDB

Что-то более сложное, чем приложение для блога в окончательном руководстве.

Давайте представим приложение, такое как переполнение стека.

  • Как сохранить основные части - пользователи, вопросы, ответы, комментарии, метки, голоса?
  • Считаете ли вы целесообразным разделить данные на разные базы данных? Например, поставить пользователей на отдельный db ... или голосов/тегов?
  • Или не потому, что в представлениях вы не можете комбинировать данные из разных баз данных?

ответ

2

Концепции, которые хорошо работают для структурирования данных в реляционных базах данных, также справедливы для баз данных хранения документов. Единственное, что действительно меняется, - это то, что запросы, которые обычно выполняются при объединении в реляционной базе данных, обычно громоздки в базе данных NoSQL. Это означает, что отношения ко многим отношениям, обычно разрешаемым с соединением на RDBM, обычно будут включать гораздо более денормализацию на базе данных NoSQL. В типичном примере отношений от одного до многих, таких как сообщения в блогах и комментарии к этому сообщению, вместо того, чтобы иметь внешний ключ в комментарии к сообщению, вы фактически дублируете некоторые данные из сообщения в комментарии, чтобы избежать лишнего запрос, и вы также сохраните список идентификаторов комментариев (и, возможно, 10 самых последних комментариев).

+0

TokenMacGuy, по внешнему ключу, вы имеете в виду Почты "_id" атрибут? Вы хотите хранить дубликаты данных в объекте комментария просто для удобства? Попытка реализовать с помощью Backbone.js, поэтому я действительно думаю об этом в процессе подготовки CRUD-операций Backbone. – AndrewHenderson 2013-01-29 07:31:58

+0

Да, вы бы связали эти два документа, добавив идентификатор родителя к атрибутам дочернего элемента. но нет, денормализация довольно неудобна, ее обычно выполняют для выполнения; couchDB может спасти вас здесь, однако, с представлениями. – SingleNegationElimination 2013-01-29 13:09:11

0

Отношении делать «присоединяется» в CouchDB:

На самом деле это может сделать больше смысла, чтобы не дублировать данные. Вот пример представления, которое я создал в couchdb: http://wamoyo.iriscouch.com/_utils/database.html?ideageneration/_design/IdeaGeneration/_view/challengesAndIdeas

Это простое приложение позволяет людям входить в вызовы, а затем давайте им собирать идеи о том, как решить эти проблемы. Это хорошо отражается на примере блога: «Задачи» - это сообщения в блогах, а идеи - это комментарии, которые подходят для каждого сообщения в блоге.

Я отправил это в полной детализации на другой вопрос здесь: Couch DB Join operations like RDBMS

Что касается структурирования приложений в CouchDB, Джейсон я играю с тем же вопросом. CouchDB предлагает большую гибкость, поэтому я не совсем уверен, следует ли использовать показы и списки для отображения данных или просто написать код на стороне клиента, чтобы сделать это, возможно, с помощью магистрали, а затем просто использовать представления couchdb для поставки модели. Позвольте мне знать, что вы придумали, мне было бы очень любопытно.

0

Предлагаю вам хранить различные части (пользователи, вопросы, ответы, комментарии, теги, голоса) в виде отдельных документов в одной базе данных.

Нет. Не храните их в отдельных базах данных. Вы потеряете силу просмотров и должны сделать экспоненциальное количество HTTP-запросов для сбора данных.

-

Заканчивать http://www.cmlenz.net/archives/2007/10/couchdb-joins. Это действительно пролило свет на эту тему для меня. Кредит Costa для обмена ссылками в another question.

Хотя в статье используется вездесущий блог, я считаю, что подход №2 с «View Collation» - это то, что вы хотите.

Документы, являющиеся дочерними элементами другого документа, будут связаны атрибутом «_id» родителя. Кроме того, вы дадите вашим документам атрибут «type» для целей их заказа при возврате в представлении. Например:

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. На мой взгляд, это именно то, что вы хотите.

Вы можете применить тот же подход ко всему, что имеет отношения «один ко многим» или «много-к-одному».

Надеюсь, это поможет!

0

Модель, приведенная в качестве примера в http://www.cmlenz.net/archives/2007/10/couchdb-joins, была полезной в понимании структуры, но у меня есть один комментарий о том, как использовать тему блога для doc id. Если у двух пользователей одинаковый заголовок блога, это вызовет конфликт. Я новичок в couchdb, но кажется, что идентификатор doc и название документа должны быть раздельными, несмотря на то, что у вас есть возможность загружать блог с/blogName. Может, все еще быть достигнуто с помощью структуры
{_id: 6377738426gdjjsb, _rev: 1-hsusubsvh6377, название: название_блога, AUTHORNAME: shakespeareND5}

Смежные вопросы