Как перестать мыслить “реляционно”

StackOverflow https://stackoverflow.com/questions/1043830

Вопрос

На работе мы недавно запустили проект с использованием CouchDB (базы данных, ориентированной на документы).Мне было нелегко отказаться от всех моих знаний о реляционной базе данных.

Мне было интересно, как некоторые из вас преодолели это препятствие?Как вы перестали мыслить реляционно и начали мыслить документально (я прошу прощения за то, что придумал это слово).

Есть какие-нибудь предложения?Полезные советы?

Редактировать:Если это имеет какое-то значение, мы используем Ruby & CouchPotato для подключения к базе данных.

Правка 2:ТАК же как и изводил меня, чтобы я принял ответ.Я выбрал тот, который, по-моему, помог мне учиться больше всего.Однако, я полагаю, по-настоящему "правильного" ответа не существует.

Это было полезно?

Решение

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

СУБД представляют собой нисходящий подход, при котором вы, разработчик базы данных, утверждаете структуру всех данных, которые будут существовать в базе данных.Вы определяете, что у Человека есть Имя, Фамилия, Отчество, Домашний адрес и т.д.Вы можете обеспечить выполнение этого с помощью RDBMS.Если у вас нет колонки о родной планете Человека, не повезло тому, кто хочет быть Человеком, у которого домашняя планета отличается от Земли;вам придется добавить столбец позже, иначе данные не смогут быть сохранены в RDBMS.Большинство программистов в любом случае делают подобные предположения в своих приложениях, так что это не глупо предполагать и применять.Определение вещей может быть хорошим.Но если вам понадобится зарегистрировать дополнительные атрибуты в будущем, вам придется добавить их.Модель отношений предполагает, что ваши атрибуты данных не сильно изменятся.

Базы данных "облачного" типа, использующие что-то вроде MapReduce, в вашем случае CouchDB, не делают вышеупомянутого предположения, а вместо этого рассматривают данные снизу вверх.Данные вводятся в документы, которые могут иметь любое количество различных атрибутов.Это предполагает, что ваши данные, по самому своему определению, разнообразны по типам атрибутов, которые они могли бы иметь.В нем говорится: "Я просто знаю, что у меня есть этот документ в базе данных Person, в котором есть атрибут HomePlanet "Eternium" и имя "Lord Nibbler", но нет фамилии". Эта модель подходит для веб-страниц:все веб-страницы представляют собой документ, но фактическое содержимое / теги / ключи документа настолько сильно различаются, что вы не можете вписать их в жесткую структуру, которую СУБД понтифицирует с самого начала.Вот почему Google считает, что модель MapReduce лучше модели soxors, потому что набор данных Google настолько разнообразен, что с самого начала необходимо учитывать неоднозначность, а из-за массивных наборов данных можно использовать параллельную обработку (которую MapReduce делает тривиальной).Модель документ-база данных предполагает, что атрибуты ваших данных могут / будут сильно меняться или быть очень разнообразными с "пробелами" и множеством малонаселенных столбцов, которые можно было бы обнаружить, если бы данные хранились в реляционной базе данных.Хотя вы могли бы использовать СУБД для хранения подобных данных, это очень быстро привело бы к уродству.

Тогда, чтобы ответить на ваш вопрос:вы вообще не можете мыслить "реляционно", когда смотрите на базу данных, использующую парадигму MapReduce.Потому что на самом деле это не имеет принудительного отношения.Это концептуальный горб, с которым вам просто придется смириться.

Хорошая статья, с которой я столкнулся, в которой довольно хорошо сравниваются две базы данных, - это MapReduce Создать:Важный Шаг Назад, в котором утверждается, что базы данных парадигмы MapReduce являются технологическим шагом назад и уступают СУБД.Я вынужден не согласиться с тезисом автора и хотел бы утверждать, что разработчику базы данных просто нужно было бы выбрать подходящую для его / ее ситуации.

Другие советы

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

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

Нереляционные / похожие на документы данные имеют смысл при денормализации.Это не сильно меняется, или вы не так сильно заботитесь о последовательности.

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

Вот хорошая статья о нереляционные базы данных.

Другой способ думать об этом заключается в том, что документ - это строка.Все, что касается документа, находится в этой строке, и это относится конкретно к этому документу.Строки легко разбиваются на части, поэтому масштабирование упрощается.

В CouchDB, как и в Lotus Notes, вам действительно не следует думать о Документе как об аналоге строки.

Вместо этого Документ представляет собой отношение (таблица).

Каждый документ содержит несколько строк - значений полей:

ValueID(PK)  Document ID(FK)   Field Name        Field Value
========================================================
92834756293  MyDocument        First Name        Richard
92834756294  MyDocument        States Lived In   TX
92834756295  MyDocument        States Lived In   KY

Каждое представление представляет собой запрос с перекрестными вкладками, который выбирает по массивному ОБЪЕДИНЕНИЮ ВСЕ элементы каждого документа.

Таким образом, это все еще отношения, но не в самом интуитивном смысле и не в том смысле, который наиболее важен:надлежащая практика управления данными.

Базы данных, ориентированные на документы, не отвергают концепцию связей, они просто иногда позволяют приложениям разыменовывать ссылки (CouchDB) или даже имеют прямую поддержку связей между документами (MongoDB).Что более важно, так это то, что DODBS не имеют схемы.В хранилищах на основе таблиц это свойство может быть достигнуто со значительными накладными расходами (см. Ответ richardtallent), но здесь это делается более эффективно.Чему нам действительно следует научиться при переходе с СУБД на DODB, так это забыть о таблицах и начать думать о данных.Это то, что sheepsimulator называет подходом "снизу вверх".Это постоянно развивающаяся схема, а не предопределенное прокрустово ложе.Конечно, это не означает, что от схем следует полностью отказаться в любой форме.Ваше приложение должно интерпретировать данные, каким-то образом ограничивать их форму - это может быть сделано путем организации документов в коллекции, путем создания моделей с методами проверки - но теперь это задача приложения.

может быть, вам стоит прочитать это http://books.couchdb.org/relax/getting-started

я сам только что услышал это, и это интересно, но понятия не имею, как реализовать это в реальном приложении;)

Единственное, что вы можете попробовать, - это получить копию firefox и firebug и поиграть с Карта и уменьшить функции в javascript.на самом деле они довольно крутые и забавные и, похоже, являются основой того, как добиться успеха в CouchDB

вот небольшая статья Джоэла на эту тему : http://www.joelonsoftware.com/items/2006/08/01.html

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top