CouchDB архитектура: Представления или документы?

голоса
2

Я пытаюсь научиться CouchDB, работая с помощью простого веб-приложения для чтения RSS. Требования:

  • Разрешить каждому пользователю импортировать X-каналы в свой список
  • Пользователь может добавлять метки к каждой ленте
  • Для каждого канала содержит список последних 50 статей в базе данных

  • Пользователь должен получить обновления каждый раз, когда какой-либо канал, он присоединяется к добавляет новые элементы к нему.

После чтения различных руководств и принципов для моделирования CouchDB документов что является большим Смежным вопросом здесь, как я полагаю , было бы структурировать:

  • Ленты

    • имя
    • Последнее обновление
  • статьи

    • FeedId
    • заглавие
    • Текст
  • пользователей

    • Я бы
    • Ленты: [feed1, feed2]
    • Теги: {смешно: [статья, Статья 2]} // Может быть, новый дб с #userid #articleid #tagname?

А затем для каждого пользователя, я бы создать представление с статьями подачи и добавления тегов к нему для представления его в пользовательском интерфейсе.

Я на правильном пути здесь? Как бы вы структурировать это?

Задан 12/05/2013 в 17:15
пользователем
На других языках...                            


2 ответов

голоса
0

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

Взаимодействия в модели RSS читатель фактически сделать эту проблему не столь хорошо подходит для CouchDB. Вы должны держать для каждого пользователя тегов, и вы (а) не хотите, чтобы держать их в документе пользователя, потому что вы должны обновить документ пользователя все время, и (б) не хочет, чтобы держать их в статье документы, потому что вы должны были бы обновить эту статью документы все время.

Я думаю, что мое идеальное решение предполагает для каждого пользователя базы данных; что бы сделать эту проблему легко сговорчивым. У вас есть подающие документы и статьи документы, и вы можете просто держать тег пользователей в документах статьи. Там вроде много дублирования (потому что вы должны хранить статьи в каждой пользовательской базе данных), но, по крайней мере, это легко (и относительно быстро) для запроса.

Ответил 16/05/2013 в 09:38
источник пользователем

голоса
0

Как вы могли видеть, NoSQL все о компромиссах, основанных на сценариях использования. В какой-то момент, вы должны будете написать мнения и запросы, и не один дизайн, который подходит всем.

В вашем случае, вы сказали , что каждый поток будет иметь только последние 50 статей, так что статьи будут быстро получить значение (и так же любые данные, связанные с ними). Так что если вы будете хранить тег в модели пользователя, вам придется обновить пользовательский объект в три раза: 1когда пользователь помечает статью, 2когда пользователь удаляет тег, и 3когда статья получает затхлую и удаляются. 3неизбежно.

Его лучше хранить тег в статье, так что они удаляются вместе со статьей.

  • Ленты

    • имя
    • Последнее обновление
  • статьи

    • FeedId
    • заглавие
    • Текст
    • Теги: { "тег-1": [ "user1", "user2", ...], "tag2": [ "user3", "user4", ...]}
  • пользователей

    • Я бы
    • Ленты: [feed1, feed2]

Вы можете видеть , что я храню тег , сгруппированных пользователем. Кроме того, можно сделать наоборот , { "user1" : "tag1", "user2" : "tag1", "user3" : "tag2", "user4" : "tag2", ... }если вы считаете , что это помогает обработки ( на основе ваших требований фильтрации).

Ответил 21/05/2013 в 20:29
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more