> В чем разница реляционных и нереляционных баз данных (JavaScript)

Короткий ответ

Реляционные базы данных (SQL) хранят данные в таблицах с фиксированной схемой и поддерживают ACID-транзакции. Нереляционные (NoSQL) используют гибкие модели - документы, key-value, графы - и жертвуют строгой согласованностью ради горизонтального масштабирования и производительности. Выбор зависит от структуры данных, требований к целостности и нагрузки.

Подробное объяснение

Основные различия:

• Модель данных: SQL - таблицы с заранее определёнными колонками и типами. NoSQL - документы (JSON, BSON), графы, key-value или wide-column.
• Схема: SQL требует строгой схемы (schema-on-write). NoSQL допускает динамическую схему (schema-on-read) - поля могут различаться в разных записях.
• Масштабирование: SQL обычно масштабируется вертикально (увеличение мощности сервера). NoSQL спроектирован для горизонтального масштабирования (добавление узлов).
• Транзакции: SQL гарантирует ACID (атомарность, согласованность, изоляция, долговечность). NoSQL часто использует BASE (Basically Available, Soft state, Eventual consistency) - жертвует строгой согласованностью ради доступности.
• Запросы: SQL использует мощный декларативный язык с JOIN, GROUP BY, подзапросами. NoSQL ограничен в сложных запросах - часто только по ключу или индексу.
• Использование: SQL для финансов, ERP, систем с жёсткими требованиями к целостности. NoSQL для real-time analytics, IoT, каталогов товаров, социальных сетей.

Для frontend-разработчика на JavaScript/Node.js: MongoDB (документная) и PostgreSQL (реляционная) - частый выбор. MongoDB удобна для хранения JSON-подобных структур, но требует осторожности с вложенными документами. PostgreSQL с JSONB даёт гибридные возможности.

На практике

В реальных проектах часто используют комбинацию: PostgreSQL для пользователей, заказов, платежей (нужна целостность) и Redis для сессий, кэша, очередей (key-value, высокая скорость). Для каталога товаров с разными атрибутами (например, одежда - размер, цвет; электроника - мощность, память) MongoDB или Elasticsearch подходят лучше, чем SQL с EAV (Entity-Attribute-Value).

Для Node.js выбор драйвера/ORM:

• SQL: pg (нативный), knex (query builder), prisma (ORM с type safety).
• NoSQL: mongoose (MongoDB ODM), ioredis (Redis), neo4j-driver (графы).

Ключевой trade-off: SQL даёт консистентность и сложные запросы, NoSQL - гибкость схемы и горизонтальное масштабирование. Для микросервисов часто используют разные БД под разные сервисы (polyglot persistence).

Пример кода

JAVASCRIPT
// SQL (PostgreSQL) - строгая схема
const { Pool } = require('pg');
const pool = new Pool({ connectionString: 'postgresql://...' });

// Создание таблицы с фиксированной схемой
await pool.query(`
  CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL,
    created_at TIMESTAMP DEFAULT NOW()
  );
`);

// Вставка - все поля обязательны
await pool.query(
  'INSERT INTO users (name, email) VALUES ($1, $2)',
  ['Alice', 'alice@example.com']
);

// NoSQL (MongoDB) - гибкая схема
const { MongoClient } = require('mongodb');
const client = new MongoClient('mongodb://localhost:27017');
await client.connect();
const db = client.db('app');

// Вставка - поля могут различаться
await db.collection('users').insertOne({
  name: 'Bob',
  email: 'bob@example.com',
  phone: '+1234567890', // дополнительное поле
  metadata: { age: 30 } // вложенный объект
});

// Другой документ - другие поля
await db.collection('users').insertOne({
  name: 'Charlie',
  email: 'charlie@example.com',
  // phone отсутствует
  preferences: { theme: 'dark' }
});

Как отвечать на собеседовании

Начни с чёткого определения: "Реляционные БД - таблицы, ACID, строгая схема. Нереляционные - гибкие модели, BASE, горизонтальное масштабирование". Приведи конкретные примеры из своего опыта: "В проекте X мы использовали PostgreSQL для заказов, потому что нужны были транзакции, и MongoDB для каталога товаров из-за разной структуры атрибутов".

Покажи понимание trade-off: "Для high-load систем с eventual consistency подходит NoSQL, но если критична целостность данных - SQL". Упомяни современные гибридные решения: "PostgreSQL с JSONB даёт реляционную строгость и гибкость документов".

Для senior-уровня важно обсудить CAP-теорему, шардирование, репликацию, выбор индексов. Свяжи с фронтендом: "Для real-time обновлений на клиенте (WebSocket, SSE) часто используют Redis как pub/sub, а для кэширования данных - его же как key-value store".

Что проверяет интервьюер

• Понимание фундаментальных различий в моделях данных и их влиянии на архитектуру.
• Умение выбирать БД под конкретные задачи, а не по модности.
• Знание CAP-теоремы и trade-off между согласованностью, доступностью и устойчивостью к разделению.
• Практический опыт: работа с драйверами, ORM, миграциями, индексами.
• Понимание, как выбор БД влияет на бэкенд и, косвенно, на фронтенд (формат данных, скорость ответа, кэширование).

Типичные ошибки

• "NoSQL всегда быстрее SQL" - неверно, скорость зависит от задачи и индексов.
• "SQL не масштабируется" - PostgreSQL и MySQL поддерживают шардирование, read replicas, кластеризацию.
• "MongoDB не поддерживает транзакции" - с версии 4.0 поддерживает multi-document ACID, но с оговорками.
• Игнорирование гибридных подходов: "Используем только SQL" или "Только NoSQL" без анализа требований.
• Путаница между разными типами NoSQL: документные, key-value, графовые - решают разные задачи.