Профессионалы/недостатки основанных на документе баз данных по сравнению с реляционными базами данных

Необходимо думать, как Вы приближаетесь, приложение в документе ориентировало путь. Если Вы просто попытаетесь копировать, как Вы смоделировали бы проблему в RDBMS тогда, то Вы перестанете работать. Существуют также различные компромиссы, которые Вы могли бы хотеть сделать. ([редактор: не уверенный, как это набрасывается на аргумент, но:] Помнят, что дизайн CouchDB предполагает, что у Вас будет активный кластер многих узлов, которые могли перестать работать в любое время. Как Ваше приложение собирается обработать один из узлов базы данных, исчезающих из-под него?)

Один способ думать об этом состоит в том, чтобы предположить, что у Вас не было компьютеров, просто печатные документы. Как Вы создали бы эффективный бизнес-процесс с помощью раздаваемых клочков бумаги? Как можно избежать узких мест? Что, если что-то идет не так, как надо?

Другой угол, о котором необходимо думать, является возможной непротиворечивостью, где Вы войдете в согласованное состояние в конечном счете, но можно быть непоследовательными в течение некоторого промежутка времени. Это - анафема на земле RDBMS, но чрезвычайно распространенный в реальном мире. Канонический пример транзакции имеет передачу денег с банковских счетов. Как это на самом деле происходит в реальном мире - через сингл атомарные транзакции или через различные банки, выпуская кредит и дебетует уведомления друг другу? Что происходит, когда Вы пишете чек?

Так позволяет взгляду на Ваши примеры:

• CRUD объектов с некоторыми полями с уникальным индексом на нем.

, Если я понимаю это правильно в терминах CouchDB, Вы хотите иметь набор документов, где некоторое именованное значение, как гарантируют, будет уникально через все те документы? Тот случай не вообще приемлем, потому что документы могут быть созданы на различных копиях.

, Таким образом, мы должны посмотреть на проблему реального мира и видеть, можем ли мы смоделировать это. Вам действительно нужны они, чтобы быть уникальными? Ваше приложение может обработать несколько документов с тем же значением? Необходимо ли присвоить уникальный идентификатор? Можно ли сделать это детерминировано? Общий сценарий, где это требуется, - то, где Вам нужен уникальный последовательный идентификатор. Это жестко для решения в реплицированной среде. На самом деле, если уникальный идентификатор требуется, чтобы быть строго последовательным относительно времени, созданного, невозможно при необходимости в идентификаторе немедленно. Необходимо ослабить по крайней мере одно из тех ограничений.

• веб-приложение электронной коммерции как ebay

я не уверен, что добавить здесь как последний комментарий, который Вы сделали на том сообщении, должен был сказать "очень полезный! спасибо". Там что-то отсутствовало в подходе, обрисовал в общих чертах там, который все еще вызывает Вас проблема? Я думал, что ответ MrKurt был довольно полон, и я добавил немного улучшения, которое уменьшит конкуренцию.

Существует ли потребность нормализовать данные?

• Да: Используйте реляционный.
• номер: Используйте документ.

Основанный на документе DBS лучше всего подходит для хранения, ну, в общем, документов. Lotus Notes является общей реализацией, и электронная почта Примечаний является примером. Поскольку, что Вы описываете, электронная коммерция, CRUD, и т.д., реляционный DBS лучше разработан для устройства хранения данных и извлечения объектов/элементов данных, которые индексируются (в противоположность документам).

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

• ProductiDID
• Описание
• UnitPrice
• TOTSIZE
• Технические характеристики

и что полевые характеристики фактически содержать ссылку в документ с техническими спецификациями продукта. Таким образом, у вас есть лучшие из обоих миров.

Я в той же лодке, сейчас мне нравится couchdb, и я считаю, что в целом функциональный стиль великолепен. Но когда именно мы начнем использовать их в Эрнесте для приложений. Я имею в виду, что да, мы все можем начать разрабатывать приложения очень быстро, без лишних хлопот, со всеми этими отвратительными заморочками о том, что нормальная форма остается в стороне и не использует схемы. Но, если чеканить фразу «мы стоим на плечах гигантов». Есть веская причина использовать РСУБД, а также нормализовать и использовать схемы. Моя старая голова оракула шатается, когда я думаю о данных без формы.

Мой главный вау-фактор на couchdb - это репликация и система управления версиями, работающие в тандеме.

Последний месяц я ломал голову, пытаясь разобраться с механизмами хранения couchdb, очевидно, он использует B-деревья, но не хранит данные, основанные на нормальной форме. Означает ли это, что это действительно действительно умно и понимает, что биты данных реплицируются, поэтому давайте просто сделаем указатель на эту запись B-дерева?

Пока я думаю о xml-документах, файлах конфигурации, файлах ресурсов, передаваемых в потоки в строки base64 .

Но я бы использовал couchdb для структурных данных. Я не знаю, любая помощь очень ценится в этом.

Может быть полезно для хранения данных RDF или даже текста произвольной формы.