Учитывая фактические данные в БД, как бы я выбрал между RDBMS и DocDBMS?

Question

Я не ищу здесь священную войну, я размышляю о распределенной архитектуре и хотел бы получить информацию о Как выбрать между СУБД и DocDBMS ?

Мы не можем отрицать возможности, которые могут быть получены с использованием СУБД (т.е. MySQL, PostgreSQL, MS Sql Server и т. Д.), Они находятся в разработке более 30 лет, и многие проблемы были продуманы и решены.

Мы также должны учитывать, что движение NoSQL / DocDBMS (MongoDB, CouchDB и т. Д.) Имеет свои сильные стороны, особенно в том, как данные хранятся, связаны и реплицируются.

При рассмотрении ДАННЫЕ и только СТРУКТУРА , когда я решу использовать БД на основе документа и когда я буду использовать реляционную БД?

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

Answer 1

Если ваши данные структурированы, RMDBS кажется очевидным выбором, если это неструктурированные данные - например, документ, то лучше всего звучит DocDBMS.

RMDBS - это скорее инструмент «бэкэнда», его можно использовать для предоставления бэкенда системы, которую вы разрабатывали.

Когда вы говорите «DocDBMS», я думаю, что вы имеете в виду больше систему управления документами (?), Которая представляет собой скорее целостное решение, которое будет включать (документировать) функции управления данными, предназначенные для конечных пользователей.

Для меня NoSQL - это просто вариант RMDBS, но для более специфичных / нишевых потребностей.

Что касается того, как выбрать: составьте список НФР, которые имеют отношение к делу, и проведите некоторый простой анализ вариантов и того, как они связаны; На ум приходят масштабируемость и производительность, а как насчет объемов данных и скорости транзакций? DR? И, конечно, важные функциональные потребности. Вас больше беспокоит качество исполнения того, что построено, или долгосрочные эволюционные качества?

Answer 2

СУБД - это просто хороший универсал, который прослужил 30 лет и не имеет признаков пометки.Такие вещи, как NoSQL и т. Д., Являются «особым случаем» для определенных применений.

Я бы использовал базу данных документов, когда у меня есть библиотека документов или аналогичная.Все остальное - это СУБД.

За исключением данных, если вы хотите продать эту систему, вам, возможно, придется ориентироваться на СУБД, например SQL Server или Oracle, чтобы обеспечить ее поддержку в инфраструктуре вашего клиента