Почему я должен использовать базу данных на основе документов вместо реляционной базы данных?

Ответ 1

Вероятно, вы не должны: -)

Второй наиболее очевидный ответ - вы должны использовать его, если ваши данные не являются реляционными. Обычно это проявляется в том, что у вас нет простого способа описать ваши данные как набор столбцов. Хорошим примером является база данных, в которой вы фактически храните бумажные документы, например. путем сканирования почты офиса. Данные - это отсканированный PDF файл, и у вас есть некоторые метаданные, которые всегда существуют (отсканированные, отсканированные по типу документа) и множество возможных полей метаданных, которые существуют где-то (номер клиента, номер поставщика, номер заказа, OCRed полный текст и т.д.). Обычно вы заранее не знаете, какие поля метаданных вы добавите в течение следующих двух лет. Такие вещи, как CouchDB, работают гораздо лучше для таких данных, чем реляционные базы данных.

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

Вероятно, наименее очевидный ответ: если вы не чувствуете боли с помощью РСУБД, оставайтесь с ним. Если вам всегда нужно работать с RDBMS, чтобы выполнить свою работу, вам может понадобиться документально ориентированная база данных.

Для более подробного списка проверьте эту публикацию Ричарда Джонса.

Ответ 2

CouchDB (с сайта )

• Сервер базы данных документов, доступный через RESTful JSON API. Как правило, реляционные базы данных не просто доступны через службы REST, но требуют гораздо более сложного SQL API. Часто эти API (JDBC, ODBC и т.д.) Довольно сложны. REST довольно просто.

• Ad-hoc и без схемы без плоского адресного пространства. Реляционные базы данных имеют сложную фиксированную схему. Вы определяете таблицы, столбцы, индексы, последовательности, представления и другие материалы. Couch не требует такого сложного, дорогого, хрупкого передового планирования.

• Распространяется, обеспечивая надежную, инкрементную репликацию с двунаправленным обнаружением и управлением конфликтами. Некоторые коммерческие продукты SQL предлагают это. Из-за SQL API и фиксированных схем это сложно, сложно и дорого. Для Couch это выглядит просто и недорого.

• Возможность ввода запросов и индексирования, оснащенная табличной системой отчетов, которая использует Javascript в качестве языка запросов. Таким образом, SQL и реляционные базы данных. Ничего нового здесь.

Итак. Почему CouchDB?

• REST проще, чем JDBC или ODBC.
• Нет схемы проще, чем схема.
• Распространяется таким образом, который кажется простым и недорогим.

Ответ 3

За глупо хранить и обслуживать данные других серверов.

В последние пару недель я играл с приложением lifestream, которое опросило мои каналы (delicious, flickr, github, twitter...) и хранит их в couchdb. Красота couchdb заключается в том, что он позволяет мне сохранять исходные данные в исходной структуре без накладных расходов. Я добавил поле "класс" для каждого документа, сохранил исходный сервер и написал класс рендеринга javascript для каждого источника.

Обобщая, всякий раз, когда ваш сервер взаимодействует с другим сервером, хранилище без схемы лучше, поскольку у вас нет контроля над схемой. В качестве бонуса couchdb использует собственные протоколы серверов и клиентов - JSON для представления и HTTP REST для транспорта.

Ответ 4

Приходит на ум быстрое развитие приложений.

Когда я постоянно меняю свою схему, меня постоянно разочаровывает необходимость поддерживать схему в MySQL/SQLite. Хотя я еще не слишком много делал с CouchDB, мне нравится, как просто разработать схему во время процесса RAD.

Случай, когда вы не хотите использовать нереляционную базу данных, - это когда у вас много отношений "многие-ко-многим"; Мне еще предстоит разобраться, как создавать хорошие функции MapReduce вокруг таких отношений, особенно если вам нужно иметь метаданные в соединении. Я не уверен, но я не думаю, что функции CouchDB Map могут вызывать собственные запросы в базе данных, поскольку это может привести к бесконечным циклам.

Ответ 5

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