Каждый раз, когда вы регистрируетесь на сайте, публикуете пост, добавляете товар в корзину или ставите лайк – где-то сохраняется информация об этом. Но где именно? И как сайт потом находит ваши данные среди миллионов других?

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

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

Что такое база данных?

База данных (БД) – это организованное хранилище информации, где данные структурированы таким образом, чтобы их было легко сохранять, искать и обрабатывать.

Можно сравнить базу данных с:

• Библиотекой – книги стоят на полках по разделам, есть каталог для поиска. Вы не ищете нужную книгу вслепую среди тысяч – вы знаете, где искать.
• Складом – товары разложены по стеллажам, каждому присвоен номер, есть система учёта. Вы можете быстро найти нужный товар, проверить остатки, забрать со склада.
• Картотекой в больнице – карточки пациентов упорядочены по фамилиям, можно быстро найти историю болезни конкретного человека.

База данных работает так же: данные организованы, имеют структуру, к ним можно обращаться по запросу.

Зачем нужны базы данных на сайтах?

Современный веб-сайт – это не просто статичные HTML-страницы. Сайты хранят огромные объёмы информации:

• Интернет-магазин: товары, категории, цены, остатки на складе, заказы, клиенты, история покупок
• Социальная сеть: профили пользователей, посты, лайки, комментарии, друзья, сообщения
• Блог: статьи, авторы, категории, теги, комментарии
• Сервис бронирования: отели, номера, брони, доступность, цены по датам

Все эти данные нужно где-то хранить, и база данных – идеальное решение. Она позволяет:

• Сохранять большие объёмы данных – миллионы записей без проблем
• Быстро искать нужное – найти товар по названию за миллисекунды
• Обновлять информацию – изменить цену товара, статус заказа
• Связывать данные между собой – заказ связан с клиентом, товаром, адресом доставки
• Обеспечивать безопасность – контролировать, кто и к каким данным имеет доступ

Реляционные базы данных: таблицы, строки, столбцы

Самый распространённый тип баз данных – реляционные. Они организуют данные в виде таблиц, похожих на таблицы Excel.

Как устроена таблица?

Представьте таблицу в Excel:

• Столбцы (поля) – это характеристики, атрибуты. Например: ID, Имя, Email, Телефон.
• Строки (записи) – это конкретные объекты. Например: один пользователь, один товар, один заказ.

Пример таблицы "Пользователи":

Каждая строка – это один пользователь. Каждый столбец – это информация о пользователе.

Первичный ключ (Primary Key)

ID в таблице – это первичный ключ. Это уникальный идентификатор каждой записи. Не может быть двух пользователей с одинаковым ID. Благодаря первичному ключу можно точно указать на конкретную запись.

Зачем это нужно? Имена могут повторяться (два Ивана Ивановых), email может измениться, а ID всегда уникален и неизменен.

Связи между таблицами

Реляционные базы называются так потому, что таблицы связаны друг с другом через отношения (relations).

Пример: интернет-магазин

У нас есть три таблицы:

Таблица "Товары":

Таблица "Клиенты":

Таблица "Заказы":

Обратите внимание: в таблице "Заказы" есть ID клиента и ID товара. Это внешние ключи (Foreign Keys) – ссылки на другие таблицы.

Заказ 5001 сделал клиент с ID = 1 (Иван Иванов), купил товар с ID = 101 (Ноутбук Dell).

Благодаря связям мы можем:

• Получить все заказы конкретного клиента
• Узнать, кто покупал определённый товар
• Посчитать общую сумму заказов клиента

Это и есть суть реляционных баз – таблицы связаны между собой через ключи.

SQL: язык общения с базой данных

Чтобы работать с реляционной базой данных, используется специальный язык – SQL (Structured Query Language).

SQL позволяет:

• SELECT – получить данные (выбрать)
• INSERT – добавить новые данные
• UPDATE – обновить существующие данные
• DELETE – удалить данные

Примеры SQL-запросов

Получить всех пользователей:

SELECT * FROM users;

Найти пользователя по email:

SELECT * FROM users WHERE email = 'ivan@example.com';

Добавить нового пользователя:

INSERT INTO users (name, email, registered_at)
VALUES ('Пётр Петров', 'petr@example.com', '2024-11-22');

Обновить цену товара:

UPDATE products SET price = 48000 WHERE id = 101;

Удалить заказ:

DELETE FROM orders WHERE id = 5001;

Получить все заказы клиента с именем:

SELECT orders.id, users.name, products.title, orders.quantity
FROM orders
JOIN users ON orders.user_id = users.id
JOIN products ON orders.product_id = products.id
WHERE users.id = 1;

Последний пример показывает JOIN – объединение данных из нескольких таблиц. Это мощная возможность реляционных баз.

Популярные реляционные СУБД

СУБД (Система Управления Базами Данных) – это программа, которая управляет базой данных: хранит файлы, обрабатывает запросы, контролирует доступ.

Популярные реляционные СУБД:

• MySQL – самая распространённая, бесплатная, используется на миллионах сайтов
• PostgreSQL – более продвинутая, с богатыми возможностями
• SQLite – лёгкая, встраиваемая база, для небольших проектов
• Microsoft SQL Server – от Microsoft, для корпоративных проектов
• Oracle Database – мощная, дорогая, для крупного бизнеса

NoSQL: альтернатива реляционным базам

Реляционные базы отлично работают, когда данные имеют чёткую структуру: товары, заказы, пользователи. Но что если данные более гибкие, неструктурированные?

Появились NoSQL-базы (Not Only SQL) – базы данных без жёстких таблиц и схем.

Типы NoSQL-баз

1. Документо-ориентированные (Document-based)

Данные хранятся в виде документов (обычно JSON-формат). Каждый документ – самостоятельная единица, может иметь свою структуру.

Пример (MongoDB):

{
  "id": 1,
  "name": "Иван Иванов",
  "email": "ivan@example.com",
  "address": {
    "city": "Москва",
    "street": "Ленина 10"
  },
  "orders": [101, 102, 105]
}

Не нужно создавать отдельные таблицы для адресов и заказов – всё в одном документе.

Популярные: MongoDB, CouchDB

2. Ключ-значение (Key-Value)

Самая простая структура: есть ключ (уникальный идентификатор) и значение (любые данные).

Пример:

user:123 → {"name": "Иван", "email": "ivan@example.com"}
session:abc456 → {"user_id": 123, "expires": "2024-11-23"}

Очень быстрые для чтения/записи, используются для кэширования.

Популярные: Redis, Memcached

3. Колоночные (Column-family)

Данные хранятся по столбцам, а не по строкам. Эффективно для аналитики больших данных.

Популярные: Cassandra, HBase

4. Графовые (Graph)

Данные представлены в виде графа: узлы (объекты) и связи между ними. Идеально для социальных сетей, рекомендательных систем.

Пример: пользователь → дружит с → другим пользователем → лайкнул → пост.

Популярные: Neo4j, ArangoDB

Когда использовать NoSQL?

• Гибкая структура данных – не все объекты имеют одинаковые поля
• Огромные объёмы – миллиарды записей, петабайты данных
• Высокая скорость записи – нужно быстро сохранять данные без сложных проверок
• Горизонтальное масштабирование – легко добавить ещё серверов
• Кэширование – временное хранение часто запрашиваемых данных (Redis)

Когда использовать реляционные базы?

• Чёткая структура – данные имеют предсказуемую схему
• Связи важны – нужно объединять данные из разных таблиц
• ACID-требования – важна согласованность данных (банки, финансы)
• Сложные запросы – нужны JOIN, GROUP BY, агрегации

Как база данных работает на практике?

Давайте проследим путь данных на примере регистрации пользователя:

1. Пользователь заполняет форму регистрации
   Имя: Иван Иванов
   Email: ivan@example.com
   Пароль: ••••••••
   Нажимает кнопку "Зарегистрироваться"
2. Фронтенд отправляет данные на бэкенд
   POST-запрос с JSON:

   {
     "name": "Иван Иванов",
     "email": "ivan@example.com",
     "password": "mypassword123"
   }

3. Бэкенд получает данные и проверяет
   - Email корректный?
   - Пароль достаточно сложный?
   - Такой email уже зарегистрирован?
4. Бэкенд хэширует пароль
   Нельзя хранить пароли в открытом виде! Пароль преобразуется в хэш (необратимое шифрование):

   mypassword123 → $2y$10$eImiTXu...

5. Бэкенд формирует SQL-запрос
   

   INSERT INTO users (name, email, password, created_at)
   VALUES ('Иван Иванов', 'ivan@example.com', '$2y$10$eImiTXu...', NOW());

6. СУБД выполняет запрос
   - Открывает файл базы данных
   - Добавляет новую строку в таблицу users
   - Присваивает автоматический ID (например, 123)
   - Обновляет индексы для быстрого поиска
   - Записывает изменения на диск
7. СУБД возвращает результат бэкенду
   "Успешно добавлена запись с ID = 123"
8. Бэкенд отправляет ответ фронтенду
   

   {
     "status": "success",
     "user_id": 123,
     "message": "Регистрация прошла успешно"
   }

9. Фронтенд показывает сообщение пользователю
   "Добро пожаловать, Иван! Вы успешно зарегистрированы."

Весь процесс занимает доли секунды.

Индексы: как база данных ищет быстро

Представьте книгу на 1000 страниц. Как найти упоминание слова "клиент-серверная модель"?

Без индекса: придётся читать все 1000 страниц подряд, пока не найдёте. Долго.

С индексом (алфавитным указателем в конце книги): смотрите в указатель → "К" → "Клиент-серверная модель – стр. 42, 89, 156". Открываете нужную страницу. Быстро.

Индекс в базе данных работает так же: это дополнительная структура, которая ускоряет поиск по определённым полям.

Пример: если часто ищете пользователей по email, создаёте индекс на поле email. Теперь поиск занимает миллисекунды вместо секунд.

Но индексы:

• Плюс: ускоряют чтение (SELECT)
• Минус: замедляют запись (INSERT, UPDATE) и занимают дополнительное место

Поэтому индексы создают только на те поля, по которым часто ищут.

Транзакции: всё или ничего

Транзакция – это группа операций, которые должны выполниться все вместе или не выполниться вообще.

Пример: перевод денег

1. Снять 1000₽ со счёта Ивана
2. Добавить 1000₽ на счёт Марии

Что если после шага 1 произошёл сбой? Деньги списались с Ивана, но не дошли до Марии. Катастрофа!

Транзакция решает проблему:

• Если обе операции прошли успешно → COMMIT (зафиксировать изменения)
• Если хотя бы одна упала → ROLLBACK (откатить всё назад, как будто ничего не было)

Банки, финансовые системы, e-commerce – везде критически важны транзакции.

ACID: гарантии надёжности

Реляционные базы данных гарантируют ACID:

• Atomicity (Атомарность) – транзакция выполняется полностью или не выполняется вообще
• Consistency (Согласованность) – база данных всегда остаётся в корректном состоянии
• Isolation (Изолированность) – параллельные транзакции не влияют друг на друга
• Durability (Долговечность) – после COMMIT данные сохранены навсегда, даже если сервер упал

ACID – это причина, почему банки используют реляционные базы. Надёжность превыше всего.

Масштабирование баз данных

Что делать, когда пользователей стало миллионы, а база данных не справляется?

Вертикальное масштабирование

Купить более мощный сервер: больше оперативной памяти, быстрее диски (SSD), мощнее процессор. Простой способ, но есть предел – самый мощный сервер когда-то закончится.

Горизонтальное масштабирование

Репликация (копирование): создать несколько копий базы. Один сервер – мастер (принимает запись), остальные – реплики (отдают данные на чтение). Ускоряет чтение.

Шардирование (разделение): разделить данные между несколькими серверами. Например, пользователи с ID 1-1000000 на первом сервере, 1000001-2000000 – на втором. Каждый сервер хранит часть данных.

Кэширование

Часто запрашиваемые данные хранятся в быстрой памяти (Redis). Вместо похода в базу данных – берём из кэша. В 10-100 раз быстрее.

Главное из статьи

• База данных – организованное хранилище информации для быстрого сохранения, поиска и обработки
• Реляционные БД – данные в таблицах (строки, столбцы), связи через ключи, язык SQL
• NoSQL – альтернатива для гибких структур: документы, ключ-значение, графы
• SQL – язык для работы с реляционными базами (SELECT, INSERT, UPDATE, DELETE)
• Индексы – ускоряют поиск, но замедляют запись
• Транзакции – группа операций "всё или ничего"
• ACID – гарантии надёжности реляционных баз
• Масштабирование – вертикальное (мощнее сервер), горизонтальное (больше серверов)

Теперь вы понимаете, где и как хранятся данные на веб-сайтах. В следующих статьях мы разберём REST API, фреймворки для веб-разработки, и наконец перейдём к практике – как всё это реализовано в платформе Shop'n'SEO!