РЕЛЯЦИОННЫЕ И НЕРЕЛЯЦИОННЫЕ БАЗЫ ДАННЫХ

Вопрос о разнице между аутентификацией и авторизацией — вечный, но мы его уже разобрали. Есть ещё один схожий: в чём разница между реляционными и нереляционными базами данных? Погнали разбираться.

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

Первое, что вам придётся решить: какую базу взять для проекта? Для начала определяемся — реляционная или нет.

Реляционная модель хранит данные в таблицах. Таблица — это фиксированная структура. Давайте сразу посмотрим пример. Многие ведут список расходов:
Дата | Сумма | Валюта | Категория | Описание
01/11 | 7.32 | USD | Еда | Кофе и бейгл в Panera Bread
01/11 | 57.95 | USD | Красота | Покрасить брови
30/10 | 1000 | руб | Блог | Реклама
28/10 | 18.22 | USD | Подписки | Book of The Month
У таблицы есть колонки — каждая несёт определённый смысл и тип. Например, в «Сумме» мы ожидаем видеть только числа отражающие денежный размер покупки. Каждая строка описывает одну конкретную трату. Всё чётко и понятно.

Введём еще одну таблицу «Категория»:
Название | Лимит в месяц | Валюта
Еда | 700 | USD
Блог | 4000 | руб
Красота | 500 | USD
Подписки | 50 | USD
Понимаем, что таблицы между собой связаны. Но в каждой — только нужные данные. В строках с тратами нет лимита по категории, он хранится отдельно.

У нас могут быть правила. Например, лимит трат. Превысили лимит в категории «Красота» — извините, подстричься уже в следующем месяце. Было бы здорово, если бы система просто блокировала проведение такой операции. Это подводит нас к одному из важнейших свойств реляционных баз — согласованности. Если у нас есть какие-то ограничения, то реляционная БД гарантирует, что после любой транзакции они будут соблюдены. Про ACID поговорим подробнее позже.

Если структура фиксированная, можно ли её менять? Можно — добавить колонку или создать новую таблицу, а потом связать её с существующими. Но это далеко не самая простая и дешевая операция.

Чтобы удобно работать с такими структурированными данными, появился язык SQL (Structured Query Language). С его помощью можно работать с любой реляционной БД — это своего рода стандарт. Язык несложный и напоминает естественные фразы. Например: «хочу получить все транзакции за октябрь по категории Красота»:

SELECT * FROM TRANSACTIONS
WHERE DATE >= '2025-10-01' AND DATE <= '2025-10-31' AND CATEGORY = 'Красота'

Примеры реляционных БД:
Microsoft SQL, MySQL, Oracle, PostgreSQL.

Что делать, если в ваших данных нет структуры или она постоянно меняется? Например, с сайта приходят анкеты в виде XML. Структура вроде есть, но "слабая": какие-то вопросы можно пропустить, где-то можно дать несколько ответов, часть пунктов скоро потеряет актуальность. Чёткая таблица уже не подходит — вам бы просто сохранить XML как документ. Для таких задач используют нереляционные БД.

Они бывают разными по способу хранения:
◾ Ключ–значение
◾ Документы
◾ Графы
◾ Временные ряды
◾ и т. д.
Разнообразие огромное: под любую задачу найдётся нереляционная база, которая справится с хранением.

Такие БД не имеют общего стандарта запросов, могут не соблюдать строгую согласованность (что, например, ускоряет запись), зато легче масштабируются ещё и горизонтально, а так же дают больше свободы.

Примеры нереляционных БД:
MongoDB, Cassandra, Redis, Neo4j, Milvus.

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

Знаете ещё какие-нибудь важные различия между реляционными и нереляционными БД? Пишите в комментариях!

#бабанюра_программирует