Блог
Теория и инструменты тестирования

Виды баз данных: SQL vs NoSQL, когда что использовать

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

Где база данных живёт в архитектуре и когда она не нужна

В классической клиент-серверной архитектуре роли распределены чётко: клиент — это то, что видит пользователь, сервер обрабатывает логику, а база данных хранит информацию. Когда клиент отправляет запрос на получение, скажем, списка товаров, сервер сам ничего не хранит — он делает запрос в базу данных, получает результат и оборачивает его в ответ, который уходит обратно клиенту.
При этом база данных нужна далеко не всегда. Если сайт — простой информационный лендинг без регистрации, без личного кабинета и без товаров, хранить попросту нечего, а значит, и полноценная база данных не требуется. Здесь работает простое правило: не стоит использовать космический корабль там, где можно дойти пешком. База данных становится необходимой, когда речь идёт об интернет-магазинах, регистрации пользователей, больших объёмах информации, хранении профилей и настроек, а также в более сложных системах вроде CRM, систем управления заказами или обучающих платформ.

Чем база данных отличается от Excel

На первый взгляд таблица в Excel или Google Таблицах напоминает базу данных — те же строки и колонки. Но у настоящей базы данных есть три принципиальных преимущества. Во-первых, объём: миллион строк в Excel превращается в мучение, а база данных спокойно работает с миллионами и миллиардами записей. Во-вторых, права доступа: в таблице обычно доступны только варианты «читать», «редактировать» или «не иметь доступа», тогда как в базе данных можно тонко настраивать права на уровне отдельных таблиц, ролей пользователей и даже конкретных полей. В-третьих, связи между данными: база данных изначально спроектирована для того, чтобы удобно хранить связанные сущности — пользователей, их заказы, товары в этих заказах, — тогда как связывать между собой листы в таблице неудобно и ненадёжно.

4 вида баз данных

Существует четыре основных типа баз данных, и они устроены по-разному.
Ключ-значение — самый простой формат, где каждому ключу соответствует одно значение, что-то похожее на структуру JSON. Классический пример — Redis. Изначально такие базы создавались как быстрое кэширующее хранилище, работающее в оперативной памяти, но сегодня они вполне могут использоваться и как полноценная база данных.
Реляционные — самый распространённый и самый старый тип, к которому относится PostgreSQL, а также MySQL, Oracle и SQL Server. Данные хранятся в связанных таблицах — строках и колонках, — а обращаются к ним с помощью языка SQL. Подавляющее большинство классических проектов вроде интернет-магазинов, CRM-систем и обучающих платформ построены именно на реляционных базах данных.
Документ-ориентированные — типичный пример NoSQL-подхода (Not Only SQL), где хранятся не данные для документов, а сами документы целиком, в гибкой структуре без жёсткой схемы таблиц. Самый известный представитель — MongoDB. Такие базы данных используют собственный язык запросов, а не SQL, и на собеседованиях тестировщика встречаются заметно реже реляционных.
Графовые — база данных, построенная на структуре графа: вершины и связи между ними. Такой формат идеально подходит там, где важны именно связи между сущностями — например, в социальных сетях или при анализе связей между людьми и организациями. Пример — OrientDB. Один из реальных кейсов такого использования — проект по сбору открытых данных о физических и юридических лицах: система собирала информацию из соцсетей, налоговой и других открытых источников и строила визуальный граф связей — кто с кем учился, через сколько промежуточных узлов связаны два человека. Такие проекты встречаются, но довольно редко.

Что такое СУБД и при чём тут SQL

Работа с базой данных всегда идёт через посредника — систему управления базами данных, СУБД. Это программа, которая умеет создавать, записывать, обновлять и удалять данные, а также менять структуру таблиц. Хорошая аналогия — библиотекарь: вы приходите с запросом, библиотекарь идёт в хранилище, находит нужную книгу и выдаёт её вам. Напрямую в хранилище книг вы не лезете — только через библиотекаря. Так же и с базой данных: клиент (обычно backend-сервер, но иногда и сам тестировщик через специальный инструмент) обращается к СУБД, а не к базе напрямую.
Самые известные СУБД для реляционных баз данных — PostgreSQL, MySQL, Oracle и SQL Server. Принципы у всех похожи, различия в основном в синтаксисе и деталях реализации, поэтому знания, полученные на одной реляционной СУБД, довольно легко переносятся на другую.
SQL, Structured Query Language, — это язык структурированных запросов, с помощью которого через СУБД создают, изменяют и удаляют данные. Он работает только с реляционными базами данных: у документ-ориентированных баз вроде MongoDB — свой собственный язык запросов. Между клиентом и сервером данные обычно передаются по протоколу HTTP, а вот взаимодействие сервера с базой данных идёт по протоколу TCP — браузер напрямую по TCP работать не умеет, поэтому всегда действует через сервер.

Когда тестировщик работает с базой данных

Чаще всего тестировщик проверяет, что данные действительно записались в базу после какого-то действия — например, после успешного создания заказа. Здесь есть два уровня проверки. Поверхностный: сделать запрос на создание, а потом запросом на чтение убедиться, что объект появился в списке — этого обычно достаточно, потому что времени на более глубокую проверку часто не хватает. Более детальный: напрямую сходить в базу данных и проверить, что запись действительно попала в нужную таблицу и с правильным типом данных, а не просто вернулся статус успеха без реальной записи — такое тоже случается, если, например, разработчик временно поставил заглушку.
Вторая типичная ситуация — создание тестовых данных напрямую через базу, когда нужного функционала (например, формы создания записи) ещё нет, но протестировать чтение данных уже нужно. В этом случае тестировщик пишет нужные записи прямо через SQL-запрос, минуя интерфейс.
Даже если на конкретном проекте тестировщик редко заходит в базу данных напрямую, знание SQL и понимание видов баз данных — это то, что почти гарантированно спросят на собеседовании. В Quality Academy на курсе «Инженер по ручному тестированию» SQL разбирают на реальной практике: запросы, фильтрацию, агрегатные функции и группировку данных студенты отрабатывают на конкретной учебной базе данных.
-------

Полезные ссылки школы

Сайт Quality Academy:
https://quality-academy.ru/main
Telegram-канал:
https://t.me/quality_academy
YouTube-канал:
https://www.youtube.com/@quality_academy
ВКонтакте:
https://vk.com/quality_academy
Канал отзывов учеников (58+ отзывов):
https://t.me/quality_academy_reviews
Задать вопрос менеджеру:
https://t.me/quality_academy_bot
Тест «Подойдёт ли вам тестирование»:
https://quiz.quality-academy.ru
5000+ вопросов с собесов тестировщика — бот-тренажёр:
https://t.me/quality_academy_interview_bot
3 практические задачи и дорожная карта:
https://t.me/quality_academy_tasks_bot
Бесплатные тренажёры — SQL Arena, Playwright Arena, Python Arena:
SQL Arena · Playwright Arena · Python Arena