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

Наверное, не стоит :-)

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

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

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

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

CouchDB (с их веб-сайта)

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

• Специально и без схемы с плоским адресным пространством. Реляционные базы данных имеют сложную фиксированную схему. Вы определяете таблицы, столбцы, индексы, последовательности, представления и прочее. Диван не требует такого сложного, дорогостоящего и хрупкого передового планирования.

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

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

Так. Почему CouchDB?

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

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

Последние пару недель я играл с приложением Lifestream, которое опрашивает мои ленты (Delicious, flickr, github, twitter ...) и сохраняет их в couchdb. Прелесть couchdb в том, что она позволяет мне сохранять исходные данные в их исходной структуре без дополнительных затрат. Я добавил поле «класс» к каждому документу, в котором хранится исходный сервер, и написал класс рендеринга javascript для каждого источника.

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

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

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

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

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

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

Моя самая большая победа в базах данных документов, которые хранят данные в формате JSON: это собственный формат для JavaScript. Таким образом, веб-приложения JavaScript невероятно хорошо работают с CouchDB. Недавно я сделал веб-приложение, которое использует CouchDB, и оно очень быстрое, а также способно обрабатывать постоянно меняющуюся структуру данных.

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

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

Еще одно преимущество - простота использования баз данных на основе документов в веб-разработке. Более подробное сравнение моделей баз данных NoSQL можно найти в этом источнике: https://arxiv.org/ftp/arxiv/papers/1509/1509.08035.pdf