Справочные данные NoSql

Ответ 1

Я полагаю, что CouchDB - это база данных NoSQL, если вы так говорите.

Но на самом деле у нас есть языки программирования общего назначения и языки, специфичные для домена. Аналогично, CouchDB - это база данных, специфичная для домена.

Я использую CouchDB много, но мне действительно все равно, использует ли он SQL или NoSQL. CouchDB ценен для меня, потому что API - это 100% HTTP, JSON и Javascript. Вы можете создавать веб-приложения с помощью браузера, выбирающего HTML из CouchDB, а затем запрашивая данные по AJAX. Сказать, что это "не SQL" - это преуменьшение!

В любом случае, вернемся к Smarty Pants и Regular Joe. Возможно, у него есть 100 000 документов. Что делать, если мы просто обновим их все, трудный путь? Ну, это довольно небольшое количество Javascript.

$.getJSON('/db/_design/cms/_view/by_user?key=Smarty+Pants', {
  success: function(result) {
    // Change the name right here, in the result objects.
    var docs = result.rows.map(function(row) {
      row.value.firstName = "Regular";
      row.value.lastName = "Joe";
      return row.value;
    })

    // Store it!
    $.post('/db/_bulk_docs', {"docs":docs}, function() {
      console.log("Done! Renamed Smarty Pants in " + docs.length + " documents!");
    })
  }
})

Да, этот метод даст вам F в классе компьютерных наук. Однако мне это нравится. Я бы написал этот код в Firebug. В моем браузере. Переименование не является атомарным и не имеет ссылочной целостности. С другой стороны, это, вероятно, завершится через пару секунд, и никто не будет заботиться.

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

P.S. Представление by_user построено из map-reduce. В CouchDB map-reduce является инкрементным, что означает, что он выполняет, как и большинство индексов SQL. Все запросы заканчиваются коротким, прогнозируемым (логарифмическим) временем.

Ответ 2

Ваши данные явно реляционные: в статье есть автор. Вы можете моделировать свои данные в магазине NOSQL, таком как MongoDB, точно так же, как и в реляционном магазине. НО, потому что в базе данных нет объединений, вам нужно сделать два вызова в базе данных, чтобы вы ничего не получили.

НО... то, что вы можете сделать с магазином NOSQL, - это денормализация данных для повышения производительности (однократное путешествие, чтобы получить все, что вам нужно для показа статьи), но за счет непосредственной согласованности: всегда точные имена авторов для окончательно точных имен авторов.

Вы можете, например, использовать это в своей статье:

author: {firstName: "Smarty", lastName: "Pants", _id:DE342624EF }

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

Многие основные веб-сайты больше не дают вам немедленной согласованности. Есть изменения, которые вы делаете, которые в конечном итоге будут видны другими пользователями на сайте.

Ответ 3

Позвольте мне заявить, что я не специалист по NoSQL любыми способами. Вместо этого мои знания об этом в основном теоретические.

Тем не менее, я твердо убежден в том, что внедрение системы типа CMS, подобной этой в NoSQL, вероятно, не самый лучший способ заниматься вещами, поскольку данные в основном реляционные.

Мое решение этой проблемы основано на предположении, что используемая вами система NoSQL позволяет загружать записи посредством структуры типа "первичный ключ". Я думаю, что большинство из них, но я уверен, что есть некоторые, которые этого не делают.

Тем не менее, я предлагаю хранить данные следующим образом.

Для автора:

{
_KEY: $AUTHOR_GUID,
firstName: "Smarty",
lastName: "Pants",
}

И для самой записи:

{
title: "Learn nosql in 5 minutes",
slug: "nosql_is_easy", 
author: $AUTHOR_GUID,
}

Обратите внимание, что в приведенном выше примере я использую _KEY, чтобы представить, что это значение типа "первичный ключ".

После загрузки сообщения вы можете загрузить автора с помощью этого GUID.

Ответ 4

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

article 
{
title: "Death to RDBMS",
slug: "rdbms_sucks", 
author: {id: "10000001"}
}

author
{
name: "Big Brother",
id: "10000001"
}

для общего предложения схемы схемы mongodb, прочитайте официальные документы

Ответ 5

Эта запись была здесь в течение некоторого времени, но я подумал, что я бы указал на другой метод обработки ссылок "join" и cross-document с CouchDB. Это метод, который я использую в CMS, который я пишу для использования CouchDB (ранее он был написан для MySQL).

CMS называется BlueInk и может быть найден на Github в http://github.com/BigBlueHat/BlueInk В настоящее время переписывание ориентировано на дизайн документа и "рендеринг двигатель", так что нет UI, о котором можно говорить - вы должны обрабатывать все JSON вручную. Это то, что я надеюсь исправить в ближайшее время, но там уже достаточно в репо (после установки в CouchDB), чтобы дать вам представление о том, как "присоединяется".

В BlueInk страница ссылается на элементы контента, которые сами могут быть включены в одну или несколько страниц (или одну и ту же страницу несколько раз). Страница ссылается на элементы страницы через их идентификатор (как в вашем втором примере JSON). При запуске через "page_and_items" вид он будет генерировать вывод, который может использоваться с параметром запроса CouchDB ?include_docs=true, чтобы вытащить полное содержимое ссылки на элементы содержимого в документе страницы.

Затем вывод результатов передается через функцию _list и отформатируется с помощью шаблона Mustache и выводится как HTML-страница - все в одном запросе GET.

Эта же схема использования ссылочных идентификаторов с ?include_docs=true может использоваться в вашем примере использования выше. Использование функции _list полностью "косметическое", но может быть полезно для реструктуризации выходного представления JSON или его шаблонирования и вывода HTML, CSV, XML и т.д.

Ответ 6

Вы можете точно моделировать свои данные с помощью playOrm И присоединяться в магазине noSQL. playOrm имеет S-SQL (масштабируемый SQL), который является поворотным в SQL, поскольку вы указываете, какие разделы вы запрашиваете. Таким образом, вы можете перейти от СУБД к noSQL и все еще иметь те же привычные инструменты, которые были использованы.