Я только начал работать с нереляционными базами данных и все еще пытаюсь осмыслить это и выяснить, какая модель будет лучшей. И я могу говорить только от лица CouchDB.
Тем не менее, у меня есть предварительные выводы:
Вы придумали альтернативный дизайн, который лучше работает в нереляционном мире?
Фокус дизайна смещается: дизайн модели документа (соответствующей таблицам БД) становится почти несущественным, в то время как все зависит от разработки представлений (соответствующих запросам).
Документная БД как бы меняет местами сложности: SQL имеет негибкие данные и гибкие запросы, документальные БД - наоборот.
Модель CouchDB представляет собой набор «документов JSON» (в основном вложенных хеш-таблиц). Каждый документ имеет уникальный идентификатор, и его можно легко получить по идентификатору. Для любого другого запроса вы пишете «представления», которые представляют собой именованные наборы функций отображения / сокращения. Представления возвращают набор результатов в виде списка пар ключ / значение.
Уловка заключается в том, что вы не запрашиваете базу данных в том смысле, в котором вы запрашиваете базу данных SQL: результаты выполнения функций представления хранятся в индексе, и можно запросить только индекс. (Как «получить все», «получить ключ» или «получить диапазон ключей».)
Самая близкая аналогия в мире SQL была бы, если бы вы могли запрашивать БД только с помощью хранимых процедур - каждый запрос, который вы хотите поддерживать, должен быть предопределен.
Дизайн документов чрезвычайно гибкий. Я нашел только два ограничения:
- Храните связанные данные вместе в одном документе, так как ничего не соответствует объединению.
- Не делайте документы настолько большими, чтобы они обновлялись слишком часто (например, все продажи компании за год в одном документе), поскольку каждое обновление документа вызывает повторную индексацию.
Но все зависит от оформления видов.
Я обнаружил, что альтернативные конструкции лучше работают с CouchDB, чем с любой базой данных SQL, на системном уровне, а не на уровне хранения. Если у вас есть некоторые данные и вы хотите передать их на веб-страницу, сложность всей системы снижается как минимум на 50%:
- нет проектирования таблиц БД (незначительная проблема)
- нет промежуточного уровня ODBC / JDBC, все запросы и транзакции через http (умеренная проблема)
- простое отображение БД в объект из JSON, что почти тривиально по сравнению с таким же в SQL (важно!)
- вы потенциально можете пропустить весь сервер приложений, так как вы можете создавать свои документы, которые будут извлекаться непосредственно браузером с помощью AJAX, и добавить небольшую доработку JavaScript, прежде чем они будут отображаться как HTML. (ОГРОМНЫЙ !!)
Для обычных веб-приложений БД на основе документов / JSON - это огромная победа, а недостатки менее гибких запросов и некоторого дополнительного кода для проверки данных кажутся небольшой платой.
Вы ударились головой о что-нибудь, что кажется невозможным?
Еще нет. Map / reduce как средство запроса к базе данных незнакомо и требует гораздо больше размышлений, чем написание SQL. Существует довольно небольшое количество примитивов, поэтому получение необходимых результатов - это в первую очередь вопрос творческого подхода к тому, как вы указываете ключи.
Существует ограничение в том, что запросы не могут просматривать два или более документов одновременно - никаких объединений или других видов многодокументных отношений, но до сих пор ничто не было непреодолимым.
В качестве примера ограничения подсчеты и суммы просты, но средние значения не могут быть рассчитаны с помощью представления / запроса CouchDB. Исправление: вернуть сумму и подсчитать отдельно и вычислить среднее значение для клиента.
Устраняли ли вы пробел с помощью каких-либо шаблонов проектирования, например, для перевода с одного на другой?
Я не уверен, что это возможно. Это скорее полный редизайн, вроде перевода программы функционального стиля в объектно-ориентированный стиль. В общем, типов документов гораздо меньше, чем таблиц SQL, и в каждом документе больше данных.
Один из способов подумать об этом - посмотреть на свой SQL на предмет вставок и общих запросов: какие таблицы и столбцы обновляются, например, когда покупатель размещает заказ? А какие для ежемесячных отчетов о продажах? Эта информация, вероятно, должна быть в том же документе.
То есть: один документ для заказа, содержащий идентификатор клиента и идентификаторы продукта, с реплицированными полями по мере необходимости для упрощения запросов. Все в документе можно легко запросить, все, что требует перекрестных ссылок между, скажем, Заказом и Заказчиком, должно выполняться клиентом. Поэтому, если вам нужен отчет о продажах по регионам, вам, вероятно, следует указать в заказе код региона.
Вы вообще сейчас делаете явные модели данных (например, в UML)?
Извините, я никогда не делал много UML до DB документов :)
Но вам нужна какая-то модель, говорящая, какие поля каким документам принадлежат и какие значения они содержат. Как для вашей справки позже, так и для того, чтобы убедиться, что все, использующие БД, знают соглашения. Поскольку вы больше не получаете сообщение об ошибке, если, например, сохраняете дату в текстовом поле, и каждый может добавить или удалить любое поле, которое ему нравится, вам понадобится как код проверки, так и соглашения, чтобы устранить провисание. Особенно, если вы работаете с внешними ресурсами.
Вам не хватает каких-либо основных дополнительных услуг, которые предоставляют РСУБД?
Нет. Но мой опыт - разработчик веб-приложений, мы имеем дело с базами данных только в той мере, в какой это необходимо :)
Компания, в которой я работал, создала продукт (веб-приложение), который был разработан для работы с базами данных SQL от нескольких поставщиков, а «дополнительные услуги» настолько отличаются от БД к БД, что их приходилось реализовывать отдельно для каждой БД. Таким образом, для нас было меньше работы по перемещению функциональности из СУБД. Это даже распространилось на полнотекстовый поиск.
Так что от того, от чего я отказываюсь, у меня вообще никогда не было. Очевидно, ваш опыт может отличаться.
Предостережение: сейчас я работаю над веб-приложением для финансовых данных, котировок акций и тому подобного. Это очень хорошо подходит для документной БД, с моей точки зрения, я получаю все преимущества БД (постоянство и запросы) без каких-либо проблем.
Но эти данные довольно независимы друг от друга, сложных реляционных запросов нет. Получайте последние котировки по тикеру, получайте котировки по тикеру и диапазону дат, получайте метаинформацию компании, вот и все. Другой пример, который я видел, - это приложение для блогов, и блоги также не характеризуются чрезвычайно сложными схемами баз данных.
Я пытаюсь сказать, что все успешные применения документных БД, о которых я знаю, были связаны с данными, которые изначально не имели много взаимосвязей: документы (как в поиске Google), сообщения в блогах, новостные статьи, финансовые данные. ,
Я ожидаю, что есть наборы данных, которые лучше сопоставляются с SQL, чем с моделью документа, поэтому я полагаю, что SQL выживет.
Но для тех из нас, кому нужен простой способ хранения и извлечения данных - а я подозреваю, что таких много, - базы данных документов (как в CouchDB) - находка.