В чем преимущество использования «документно-ориентированной СУБД»? - PullRequest
Новая
       34

В чем преимущество использования «документно-ориентированной СУБД»?

2 голосов
/ 15 ноября 2009

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

Теперь я, безусловно, вижу некоторую пользу от шаблона проектирования, но зачем мне использовать «документно-ориентированную СУБД», а не просто создавать ее с использованием традиционной базы данных, такой как SQL Server, Oracle или Postgres?

Ответы [ 3 ]

4 голосов
/ 15 ноября 2009

Мне понравилось слушать еженедельную серию нить о CouchDB. Там много рассуждений и идей.

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

Ваш пробег может отличаться, но это мне очень помогло.

0 голосов
/ 20 мая 2017

почему я хочу использовать «документно-ориентированную СУБД» вместо построение его с использованием традиционной базы данных, такой как SQL Server, Oracle или Postgres?

Исторически ориентированные на документы СУБД не позволяют распределять транзакции ACID по документам. Они плохо поддерживают Foreign Keys . Торговля должна предусматривать более доступные операции, обслуживание и масштабирование.

0 голосов
/ 15 ноября 2009

Полагаю, вы имеете в виду такие продукты, как Couch DB или Tokyo Cabinet (а не продукты ECM, такие как Documentum). Я думаю, что привлекательность для многих разработчиков знакомство.

Во-первых, концептуальная модель (в большинстве случаев) представляет собой пары ключ-значение, как файл конфигурации. Поскольку большинство фреймворков, похоже, требуют много сбоев конфигурации, разработчики интерфейсного / среднего уровня удобны в работе. Во-вторых, эти инструменты предлагают интерфейсы на языках, удобных для разработчиков, таких как Java, Python и т. Д.

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

...