Какие плюсы и минусы у реляционных (SQL) баз данных?

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

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

Что в них хорошего, блядь:

• ACID-транзакции. Это вообще святое. Представь, ты переводишь бабки с карты на карту. С твоей снялось, а на другую не дошло — пиздец же? Так вот ACID гарантирует, что либо всё пройдёт, либо нихуя. Либо деньги ушли и пришли, либо остались на месте. Как атом — неделимый. Красота.
• Строгая схема. Всё по полочкам, как у перфекциониста-алкаша в гараже. Каждая таблица — это ящик с подписью. Болты М10 только в ящик «Болты М10». Гайки — в «Гайки». Попробуй сунуть болт в ящик с гайками — получишь по ебалу от системы. Целостность данных, ёпта. Никаких «ой, а я тут JSON-чик впихнул в поле для даты».
• Мощный SQL. Это их козырь, их конёк. Один запрос может сделать такое, что в NoSQL придется городить огород из трёх отдельных вызовов и ещё на клиенте склеивать. JOIN'ы, агрегации, вложенные подзапросы — это сила.
• Индексы. Волшебная палочка для скорости. Без индекса поиск по имени в таблице на миллион строк — это как искать иголку в стоге сена голой жопой. Создал индекс — и всё летает. Но помни: индексы — они как девушки, чем их больше, тем медленнее ты вставляешь новые записи. Тут баланс нужен.

А теперь, где они сосут и пизда им:

• Масштабирование. Вот тут начинается боль. Хочешь размазать базу на десять серверов, потому что данные не помещаются? Это называется шардинг, и это адская, ебаная работа. Ты сам должен решать, какой кусок данных на какой сервер положить, и потом с этим жить. NoSQL-ки с этим зачастую из коробки дружат.
• Жёсткость схемы. Твоё приложение живое, оно меняется. «О, а давайте к пользователю ещё номер телефона добавим и список любимых покемонов!». В NoSQL — хуяк и поле favoritePokemons: []. В SQL — надо лезть в базу, ALTER TABLE делать, миграции писать, следить, чтобы старый код не сломался. Гемор.
• Производительность на овердохуища данных. Представь, у тебя две таблицы: Users (10 млн человек) и Orders (100 млн заказов). И тебе надо вытащить всех пользователей из Москвы с их заказами за прошлый год. JOIN таких монстров может заставить сервер вспотеть так, что он тебе откажется. Иногда проще денормализовать данные (то есть нарушить свои же святые принципы), чем ждать этот запрос.
• Избыточность для простоты. Если тебе нужно просто кешировать сессию пользователя по ключу session_id, то разворачивать для этого PostgreSQL — это как охотиться на муху с ракетной установкой. Простой Redis (ключ-значение) справится в сто раз быстрее и проще.

Ну и пример, как это выглядит в коде, чтобы не быть голословным:

-- Создаём таблицу пользователей. Всё чётко, всё по схеме.
CREATE TABLE Users (
    Id INT PRIMARY KEY, -- Главный ключ, уникальный, немутируемый
    Name NVARCHAR(100) NOT NULL, -- Имя, обязательно, не больше 100 символов
    Email NVARCHAR(100) UNIQUE, -- Почта, и чтобы неповторимая, сука
    CreatedAt DATETIME DEFAULT GETDATE() -- Дата создания, сама подставится
);

-- А вот и наш волшебный ускоритель. Теперь поиск по имени не будет тупить.
CREATE INDEX IX_Users_Name ON Users(Name);

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