Я думаю, что после просмотра нескольких страниц на эту тему все зависит от типов данных, с которыми вы имеете дело.
СУБД представляют собой нисходящий подход, при котором вы, разработчик базы данных, утверждаете структуру всех данных, которые будут существовать в базе данных. Вы определяете, что у Лица есть Имя, Фамилия, Отчество и Домашний Адрес и т. Д. Вы можете принудительно применить это, используя СУБД. Если у вас нет столбца для HomePlanet Персона, то вам повезло, что вам нужно быть Person, у которого HomePlanet отличается от Earth; вам придется добавить столбец позднее, иначе данные не могут быть сохранены в РСУБД. Большинство программистов в любом случае делают подобные предположения в своих приложениях, так что это не глупая вещь, которую можно принять и применить. Определение вещей может быть хорошим. Но если вам потребуется регистрировать дополнительные атрибуты в будущем, вам придется добавить их. Реляционная модель предполагает, что ваши атрибуты данных не сильно изменятся.
Базы данных «облачного» типа, использующие что-то вроде MapReduce, в вашем случае CouchDB, не делают вышеизложенное предположение, а вместо этого смотрят на данные снизу вверх. Данные вводятся в документы, которые могут иметь любое количество различных атрибутов. Предполагается, что ваши данные по определению различаются по типам атрибутов, которые могут иметь. Он говорит: «Я просто знаю, что у меня есть этот документ в базе данных Person, который имеет атрибут HomePlanet« Eternium »и FirstName« Lord Nibbler », но не« LastName ».» Эта модель подходит для веб-страниц: все веб-страницы являются документом, но фактическое содержание / теги / ключи документа настолько сильно различаются, что вы не можете вписать их в жесткую структуру, из-за которой СУБД широко распространяет свои знания. Вот почему Google думает, что модель MapReduce roxors soxors, потому что набор данных Google настолько разнообразен, что его необходимо встроить для неоднозначности с самого начала, и из-за массивных наборов данных можно использовать параллельную обработку (которую MapReduce делает тривиальной) , Модель базы данных документов предполагает, что атрибуты ваших данных могут / будут сильно изменяться или будут очень разнообразными с "пробелами" и множеством малонаселенных столбцов, которые можно было бы найти, если данные были сохранены в реляционной базе данных. Хотя вы могли бы использовать СУБД для хранения таких данных, это было бы ужасно быстро.
Чтобы ответить на ваш вопрос: вы не можете думать «реляционно» вообще, когда смотрите на базу данных, которая использует парадигму MapReduce. Потому что на самом деле это не имеет принудительного отношения. Это концептуальный горб, который вам просто нужно преодолеть.
Хорошая статья, с которой я столкнулся и которая довольно хорошо сравнивает и сравнивает две базы данных: MapReduce: важный шаг назад , в которой утверждается, что базы данных парадигмы MapReduce являются технологическим шагом назад и уступают СУРБД. Я должен не согласиться с тезисом автора и утверждать, что разработчик базы данных просто должен выбрать правильный вариант для своей ситуации.