Для большинства современных приложений есть решение получше — и, по иронии судьбы, в его названии также есть слово «SQL».

Скорее всего, вы выросли в мире, где реляционные базы данных были единственным практичным выбором для корпоративных приложений. SQL преподавали на каждом вводном курсе по базам данных, и ожидалось, что старшие инженеры будут иметь многолетний опыт проектирования, развертывания и обработки запросов к реляционным базам данных.

Но сегодняшние базы данных сильно отличаются от того, что было 20 лет назад. Хотя SQL сохраняет свою популярность в программном обеспечении, таком как MySQL и PostgreSQL, некоторые современные веб-приложения обратились к решениям NoSQL, таким как MongoDB.

Когда я впервые начал создавать веб-приложения, я предполагал, что реляционные базы данных являются стандартом, потому что они просто лучше. Я почти не рассматривал решения NoSQL.

Но когда я впервые попробовал MongoDB, я осознал серьезную ошибку, которую совершил, так долго не обращая внимания на нереляционные базы данных.

Теперь я выбираю MongoDB для большинства своих новых проектов. Вот почему.

Полная интеграция с экосистемой JS

Node.js действительно является первоклассным гражданином MongoDB. Схемы могут быть сопоставлены непосредственно с типами TypeScript, а документы могут быть преобразованы непосредственно в объекты. Разработка любого программного обеспечения упрощается, когда ваши программные компоненты говорят на одном языке.

Кроме того, драйверы MongoDB имеют простой и интуитивно понятный API. Невероятно легко просто подключиться и начать делать запросы.

Этот вопрос спорный для программного обеспечения, разработанного с использованием чего-либо, кроме Node.js. Но поскольку TypeScript — это мой личный выбор для большинства серверных приложений — и его популярность резко возросла как среди стартапов, так и среди предприятий — эта более естественная интеграция с Node.js только еще больше повысила популярность MongoDB.

Атлас

Редко когда облачный сервис сам по себе может заставить архитектора программного обеспечения выбрать конкретный технологический стек, но именно это Atlas сделал со мной. Это официальный сервис облачного хостинга для MongoDB, а его бесплатный тариф достаточно мощный и быстрый даже для небольших производственных проектов.

Вы можете задаться вопросом, что такого хорошего в Atlas, если локальная установка SQL-сервера также бесплатна. Есть две причины, по которым вы можете предпочесть Atlas.

Во-первых, его проще настроить. Настройка баз данных может быть сложной задачей, особенно если вы работаете в незнакомой операционной системе или никогда раньше не устанавливали базу данных на этом компьютере. С Atlas этот процесс занимает всего несколько минут и управляется простым в использовании веб-интерфейсом. Как только база данных будет запущена, вы получите единую строку подключения, которую вы можете добавить в свой файл env, и вы готовы к работе.

Другим преимуществом является совместное использование базы данных разработки на разных машинах. Часто вы хотите, чтобы ваши базы данных разработки были разделены (это также легко сделать в MongoDB). Но что, если вы хотите получить доступ к одним и тем же данным на разных машинах? Использование базы данных, размещенной в облаке, означает, что любой может использовать вашу строку подключения для просмотра тех же данных, что и у вас.

Эти причины могут показаться не очень убедительными, но Atlas настолько прост в настройке, что у вас нет причин не попробовать и не убедиться в этом самостоятельно.

Нет миграции

Миграции, несомненно, являются самой неприятной частью использования баз данных SQL. Принудительная схема означает, что каждый раз, когда вы хотите изменить структуру своей базы данных — даже незначительно — вам нужно будет написать (или сгенерировать) файл миграции и запустить его на каждой имеющейся у вас базе данных. Если вы ошибетесь, вы окажетесь в неразрешимом клубке миграций, откатов и, возможно, даже отсутствующих данных.

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

Но NoSQL имеет свою цену

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

Оптимизированная производительность

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

Однако все еще бывают редкие случаи, когда дополнительная производительность реляционных баз данных является неотъемлемой частью бесперебойного взаимодействия с пользователем.

Целостность данных

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

Вам нужно объединить много данных

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

Большинство баз данных NoSQL (включая MongoDB) имеют некоторый API для объединения таблиц и агрегирования данных, но они, как правило, не так эффективны, потому что нереляционные базы данных просто не предназначены для запросов больших данных.

NoSQL меняет правила игры с базами данных

Хотя SQL когда-то был единственным практичным выбором для производственных баз данных, базы данных NoSQL, такие как MongoDB, сделали свои случаи более естественными и современными подходами к крупномасштабному постоянному хранению данных.

Поскольку популярность Node.js для серверных приложений продолжает расти, можно ожидать, что все больше и больше разработчиков откажутся от SQL и перейдут к базам данных на основе документов.

Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter и LinkedIn. Присоединяйтесь к нашему сообществу Discord.