Как бы вы спроектировали блог, используя хранилище документов (например, CouchDB, Redis, MongoDB, Riak и т. д.)

Прежде всего, я думаю, вы захотите удалить Redis из списка, так как это хранилище ключей и значений, а не хранилище документов. Riak также является хранилищем ключей и значений, но вы можете использовать его как хранилище документов с такой библиотекой, как Ripple.

Вкратце, чтобы смоделировать приложение с хранилищем документов, нужно выяснить:

1. What data you would store in its own document and have another document relate to it. If that document is going to be used by many other documents, then it would make sense to model it in its own document. You also must consider about querying the documents. If you are going to query it often, it might be a good idea to store it in its own document as you would find it hard to query over embedded document.
   • For example, assuming you have multiple Blog instance, a Blog and Article should be in its own document eventhough an Article may be embedded inside Blog document.
   • Другой пример — пользователь и роль. Имеет смысл иметь для них отдельный документ. В моем случае я часто запрашиваю пользователя, и было бы проще, если бы он был отделен как отдельный документ.

2. Какие данные вы хотели бы сохранить (встроить) в другой документ. Если этот документ принадлежит только одному документу, то «может быть» хорошим вариантом для его хранения в другом документе.

   • Comments sometimes would make more sense to be embedded inside another document

   { article : { comments : [{ content: 'yada yada', timestamp: '20/11/2010' }] } }

   Еще одно предостережение, которое вы хотели бы рассмотреть, — это размер встроенного документа, потому что в mongodb максимальный размер встроенного документа составляет 5 МБ.

3. What data should be a plain Array. e.g:
   • Tags would make sense to be stored as an array. { article: { tags: ['news','bar'] } }
   • Или, если вы хотите сохранить несколько идентификаторов, т.е. пользователя с несколькими ролями { user: { role_ids: [1,2,3]}}

Это краткий обзор моделирования с помощью хранилища документов. Удачи.

1. Решение о том, какие объекты должны быть независимыми, а какие должны быть встроены как часть других объектов, в основном зависит от баланса производительности/затрат на чтение/запись. Если дочерний объект является независимым, его обновление означает изменение только одного документа, но при чтении родительского объекта вы имеют только идентификаторы и нуждаются в дополнительных запросах для получения данных. Если дочерний объект встроен, все данные находятся прямо там, когда вы читаете родительский документ, но для внесения изменений необходимо найти все документы, в которых используется этот объект.

2. Связывание между документами мало чем отличается от SQL — вы сохраняете идентификатор, который используется для поиска соответствующей записи. Ключевое отличие состоит в том, что вместо фильтрации дочерней таблицы для поиска записей по родительскому идентификатору у вас есть список дочерних идентификаторов в родительском документе. Для отношений многие-многие у вас будет список идентификаторов с обеих сторон, а не таблица посередине.

3. Возможности запросов сильно различаются между платформами, поэтому нет четкого ответа, как к этому подойти. Однако, как правило, вы обычно будете настраивать представления/индексы при написании документа, а не просто сохранять документ и запускать специальные запросы позже, как в случае с SQL.

Райан Бейтс пару недель назад сделал скринкаст о монгоиде и использует пример приложения для блога: http://railscasts.com/episodes/238-mongoid это может быть хорошим местом для начала.