В чем разница между реляционной и нереляционной БД?

Основное отличие: структура данных и схема

Ключевое различие между реляционными (SQL) и нереляционными (NoSQL) базами данных заключается в способе организации, хранения и связи данных.

Реляционные базы данных (SQL)

Основаны на реляционной модели данных, предложенной Эдгаром Коддом. Данные организованы в строго структурированные таблицы (отношения) с фиксированными строками и столбцами.

Характеристики:

• Строгая схема (Schema): Структура данных (таблицы, колонки, типы данных) определяется заранее и должна соблюдаться для всех записей.

  CREATE TABLE Users (
      id INT PRIMARY KEY,
      name VARCHAR(100) NOT NULL,
      email VARCHAR(255) UNIQUE,
      created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
  );
  

• Связи через ключи: Таблицы связываются друг с другом с помощью первичных (Primary Key) и внешних (Foreign Key) ключей, что обеспечивает целостность данных и устраняет избыточность (нормализация).
• Язык запросов SQL: Для взаимодействия используется стандартизованный язык структурированных запросов (SQL).
• ACID-транзакции: Гарантируют Атомарность, Согласованность, Изоляцию и Долговечность операций. Это критически важно для финансовых систем, где перевод денег между счетами должен быть либо полностью выполнен, либо полностью отменен.

Типичные представители: PostgreSQL, MySQL, SQLite (часто используется в Android для локального хранения структурированных данных).

Нереляционные базы данных (NoSQL)

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

Основные типы и их особенности:

1. Документно-ориентированные (например, MongoDB, Firebase Firestore):

    *   Хранят данные в виде гибких документов (часто в JSON или BSON формате).
    *   У каждого документа может быть своя уникальная структура.
    *   Идеальны для каталогов товаров, профилей пользователей, контента.

```json
// Два документа в одной коллекции могут иметь разную структуру
{
    "_id": "user_123",
    "name": "Анна",
    "email": "anna@mail.com",
    "preferences": { "theme": "dark", "language": "ru" }
},
{
    "_id": "user_456",
    "username": "ivan_tech",
    "level": 5,
    "achievements": ["first_post", "verified"]
}
```

2. Ключ-значение (например, Redis, Amazon DynamoDB):

    *   Простейшая модель: уникальный ключ ассоциирован со значением (строкой, JSON, blob).
    *   Максимальная скорость чтения/записи для простых операций.
    *   Используются для кэширования, сессий, счетчиков.

1. Колоночные (например, Cassandra, HBase):

    *   Хранят данные не по строкам, а по колонкам, что ускоряет агрегацию данных и аналитические запросы по определенным полям.
    *   Подходят для систем аналитики (Big Data).

1. Графовые (например, Neo4j):

    *   Представляют данные как узлы и связи (ребра) между ними.
    *   Оптимальны для сложных взаимосвязей: социальные сети, рекомендательные системы, fraud-детекция.

Общие черты NoSQL:

• Гибкая или отсуствующая схема (Schema-less): Структура данных может меняться "на лету" для разных записей.
• Горизонтальная масштабируемость (шардирование): Легче распределять данные на множество серверов (нод) для обработки очень больших нагрузок.
• Отказ от JOIN и сложных отношений: Связи часто моделируются денормализацией (дублированием данных) для скорости чтения.
• BASE vs ACID: Часто жертвуют строгой согласованностью (ACID) в пользу доступности и устойчивости к разделению (CAP-теорема). Модель BASE (Basically Available, Soft state, Eventually consistent) — данные станут согласованными в конечном счете.

Когда что выбирать (с точки зрения Android-разработки)?

• Выбирайте SQL/SQLite, когда:

    *   Данные имеют четкую, неизменную структуру (например, список транзакций в банковском приложении).
    *   Критически важна **целостность данных** и поддержка сложных связей между сущностями.
    *   Выполняются сложные аналитические запросы с агрегацией, сортировкой, фильтрацией.
    *   Работа ведется полностью **оффлайн** на устройстве.

• Выбирайте NoSQL (часто облачные, как Firestore), когда:

    *   Структура данных **неоднородна** и может быстро меняться (например, данные разных типов пользователей, динамические формы).
    *   Требуется **масштабируемость** и высокая доступность для миллионов пользователей.
    *   Приложение ориентировано на **онлайн-работу** и реальное время (чаты, коллаборативные приложения).
    *   Скорость записи и простота разработки в ущерб сложным запросам и строгой согласованности.

Современный тренд — полиглотное хранение данных: использование разных типов БД в одном проекте для решения разных задач (например, SQLite для локального кэша оффлайн-данных и Firebase Firestore для облачной синхронизации и реального времени).