Первоначально Написано Базз Москетти
Когда мы в последний раз остановились в нашей серии блогов MongoDB vs SQL, мы рассмотрели первый и второй день создания одного и того же приложения с использованием MongoDB против SQL с использованием сравнений кода. Прежде чем перейти к следующей паре дней, давайте снова пройдемся по основным правилам:
- Мы будем использовать Java
- Предположим, у нас есть слой доступа к данным между нашим приложением и MongoDB
- С точки зрения даты, которую мы просматриваем в примерах, просто рассматривайте их как индикаторы прогресса, а не фактическое время, необходимое для выполнения указанной задачи.
- Мы не будем вдаваться в исключения или обработку ошибок. Мы не будем путать код с шаблонной или персисторной логикой, которая не меняется со дня на день. Мы не будем входить в соединение с базой данных или другие ресурсы установки. Основное внимание будет уделено основному коду обработки данных.
Теперь давайте рассмотрим различия между SQL и MongoDB для дней с 3 по 5.
SQL против MongoDB: день третий
Мы уже рассмотрели сохранение и выборку данных с использованием карты Java в качестве носителя данных на уровне доступа к данным и добавили несколько простых полей. На третий день мы собираемся добавить несколько телефонных номеров в структуру.
Задача: добавить список телефонных номеров
Вот где мы были:
m.put(“name”, “buzz”); m.put(“id”, “K1”); m.put(“title”, “Mr.”); m.put(“hireDate”, new Date(2011, 11, 1));
С каждым номером телефона связан тип, «дом» или «работа». Я также знаю, что, возможно, я хочу связать другие данные с номером телефона в ближайшем будущем, например, с флагом «не звонить». Список подструктур — отличный способ упорядочить эти данные и дает мне много возможностей для роста. Это очень легко добавить это к моей карте:
n1.put(“type”, “work”); n1.put(“number”, “1-800-555-1212”)); n1.put(“doNotCall”, false); // throw one in now just to test... list.add(n1); n2.put(“type”, “home”)); n2.put(“number”, “1-866-444-3131”)); list.add(n2); m.put(“phones”, list);
Код персистентности, однако, это отдельная история.
SQL Day 3 — вариант 1. Предполагается, что только один рабочий и один домашний телефонный номер
С SQL:
Это просто плохо, но здесь стоит отметить, потому что мы видели это много раз, часто намного позже, чем на третий день, когда есть сильная мотивация избегать создания новой таблицы. С этим кодом мы предполагаем, что у людей есть только один домашний и один рабочий телефон. Давайте возьмем большую дорогу в третий день и смоделируем ее правильно в реляционной форме.
SQL Day 3: вариант 2: правильный подход с несколькими телефонными номерами
Здесь мы делаем это правильно. Мы создали таблицу телефонов и обновили способ взаимодействия с ним с помощью объединений.
Вы можете видеть, что добавление простого списка данных отнюдь не тривиально. Мы снова сталкиваемся с проблемой «изменения таблицы», потому что SQL не будет работать, если он не будет указывать на базу данных, которая была преобразована в новую схему. Методы кодирования, используемые для сохранения и извлечения контакта, начинают расходиться; сторона сохранения не «выглядит» как сторона извлечения. И, в частности, вы заметите, что получение данных уже не так просто, как встраивание их в карту и их передача обратно. При объединениях один или несколько (как правило, много) столбцов повторяются снова и снова. Ясно, что мы не хотим возвращать такую избыточную прямоугольную структуру на уровне доступа к данным и обременять приложение. Мы должны «раскрутить» набор результатов SQL и тщательно воссоздать желаемый результат, который представляет собой одно имя, связанное со списком телефонных номеров и типов.
Такая размоточная работа требует времени и денег. Многие полагаются на ORM, такие как Hibernate, чтобы позаботиться об этом, но рано или поздно логика ORM, необходимая для раскручивания сложного запроса SQL, приводит к неприемлемым проблемам с производительностью и / или ресурсами — и в конечном итоге вам приходится кодировать решение, подобное показанному выше в любом случае.
SQL день 5: зомби
С SQL вам придется иметь дело с зомби: (z) ero (o) r (m) ore (b) etween (e) nitities. Мы не можем забыть, что у некоторых людей в нашем списке контактов нет телефонов. Наш предыдущий запрос, представляющий собой простое объединение, создает декартово произведение и не возвращает людей без хотя бы одного телефона.
Чтобы решить эту проблему, мы должны вернуться и изменить запрос, чтобы выполнить внешнее соединение. Но гораздо важнее то, что это также означает изменение логики раскрутки, потому что мы не хотим добавлять пустые номера телефонов в наш список. Это займет еще больше времени и денег.
Кроме того, несмотря на то, что логика на основе SQL обременяет нас, по крайней мере, мы ограничиваем влияние только уровнем доступа к данным. Представьте себе влияние, если бы у нас не было уровня доступа к данным, а приложения сами создавали SQL и логику раскручивания. Добавление списка телефонных номеров было бы серьезной задачей.
MongoDB День 3
Теперь давайте взглянем на то, что мы только что рассмотрели, на этот раз с MongoDB: 
С MongoDB изменений нет. Список телефонных номеров, который на самом деле представляет собой список структур с номерами и типами, поступает в MongoDB и изначально хранится в виде списка структур. Как и во второй день, мы решили вернуться и заполнить телефонную информацию для тех записей, которые уже есть в базе данных. Прошло бремя необходимости создания другой таблицы, другого набора внешних ключей, управления этими ключами и добавления еще одного соединения в то, что в конечном итоге станет очень сложным выражением SQL. Нам также не нужно сразу же переходить к дизайну «один или более против нуля или более». Время и усилия, сэкономленные с документами MongoDB богатой формы, значительны.
На следующей неделе мы углубимся еще глубже, добавив материал из внешних источников в нашу структуру контактов и представив компромиссы, которые группы разработчиков делают в SQL / RDBMS, на более поздних этапах разработки.
В то же время, если вам нужна дополнительная информация о миграции, подпишитесь на наш вебинар «
Лучшие практики для перехода с СУБД на MongoDB» .