Основы баз данных — итоги
Кратко — что стоит унести из раздела "Основы баз данных". Если пункт кажется туманным — откройте указанную главу или оглавление.
FAQ — Часто задаваемые вопросы
Типичные проблемы новичков при проектировании и работе с БД. Здесь — что делать и где копать в главах; определения для зачёта — в чек-листе.
Вопрос. "У нас же Excel — зачем PostgreSQL для списка клиентов?"
Ответ. Excel слаб при одновременной записи, транзакциях, ограничениях целостности и объёме. БД нужна, когда данные общие, критичные и растут. Подробнее здесь — Знакомство с базами данных.
Вопрос. Дублируются строки пользователей с одним email — "уникальность на глаз".
Ответ. Без UNIQUE или первичного ключа СУБД не запретит дубликат. Добавьте ограничение на уровне схемы, а не только проверку в коде. Подробнее здесь — Entity Relationship.
Вопрос. Удалили родительскую запись — дочерние "висят" с битым foreign key.
Ответ. Задайте политику ON DELETE CASCADE / RESTRICT / SET NULL при проектировании. Без FK приложение со временем накопит мусор. Подробнее здесь — Entity Relationship.
Вопрос. SELECT * на таблице 10 млн строк "положил" сайт.
Ответ. Полное сканирование без WHERE и LIMIT тянет все страницы с диска. Выбирайте нужные столбцы, фильтруйте, пагинируйте; проверьте индексы. Подробнее здесь — Как СУБД выполняет запрос.
Вопрос. Добавил индекс на всё — INSERT стал в 10 раз медленнее.
Ответ. Каждый индекс — дополнительная запись при INSERT/UPDATE. Индексируйте столбцы из WHERE/JOIN, не "на всякий случай". Подробнее здесь — Как СУБД выполняет запрос.
Вопрос. Запрос "работал быстро", после импорта данных — минуты.
Ответ. После массовой загрузки устарела статистика — оптимизатор выбрал seq scan. Запустите ANALYZE/VACUUM (зависит от СУБД). Подробнее здесь — Как СУБД выполняет запрос.
Вопрос. WHERE status = NULL не находит строки с NULL.
Ответ. В SQL сравнение с NULL через = даёт UNKNOWN. Используйте IS NULL / IS NOT NULL. Подробнее здесь — Теоретические основы.
Вопрос. Два пользователя одновременно меняют одну строку — "пропали" чужие правки.
Ответ. Нужны транзакции и изоляция (MVCC, блокировки или optimistic locking с версией строки). Подробнее здесь — Конкурентный доступ.
Вопрос. Приложение висит с "Lock wait timeout" на UPDATE.
Ответ. Другая транзакция держит блокировку строки или таблицы. Найдите blocking session, сократите длинные транзакции, одинаковый порядок блокировок. Подробнее здесь — Конкурентный доступ.
Вопрос. "Сделаем бэкап" — но после сбоя потеряли последний час данных.
Ответ. Файловый бэкап без WAL/archive не даёт point-in-time recovery. Уточните RPO/RTO и политику журналирования. Подробнее здесь — Восстановление после сбоя.
Вопрос. Сразу выбрали MongoDB "потому что модно" — схема расползлась.
Ответ. Проектирование начинают с предметной области и ER, не с бренда СУБД. Документная модель тоже требует согласованной структуры. Подробнее здесь — Знакомство с базами данных, Entity Relationship.
Вопрос. M:N связь "запихнули" в одну таблицу через CSV в столбце.
Ответ. Список ID в строке ломает 1НФ и запросы. Нужна промежуточная таблица связи с двумя FK. Подробнее здесь — Entity Relationship.
Вопрос. JOIN вернул в 100 раз больше строк, чем ожидалось.
Ответ. Часто декартово произведение — забыли условие ON или неверная кардинальность M:N. Проверьте ER-модель и ключи JOIN. Подробнее здесь — Entity Relationship, SQL — реляционная модель.
Вопрос. Путаю relation (таблица) и relationship (связь на ER) — на созвоне наступает неловкая пауза.
Ответ. Relation — отношение Кодда (таблица); relationship — линия между сущностями на диаграмме. На практике relationship → FK + JOIN. Подробнее здесь — Знакомство с базами данных.
Вопрос. SQLite "на проде" под нагрузкой — database is locked.
Ответ. SQLite — встраиваемая СУБД с ограниченной конкуррентной записью; для многопользовательского web-backend чаще PostgreSQL/MySQL. Подробнее здесь — СУБД в экосистеме.
Вопрос. ORM создал таблицы — миграции не нужны?
Ответ. Auto-sync в prod опасен: потеря данных при alter. Схема — версионируемые миграции (Flyway, Liquibase, Alembic). Подробнее здесь — Роль базы данных в организации.
Вопрос. Нормализацию "отложим" — потом всё свалили в одну широкую таблицу.
Ответ. Без нормализации рано или поздно появятся аномалии при обновлении и дубли. Сначала 3НФ на логическом уровне, денормализация — осознанно под отчёты. Подробнее здесь — Нормализация.
Вопрос. SELECT COUNT(*) на большой таблице каждый раз сканирует всё.
Ответ. Точный count без условий часто полный seq scan. Используйте приближённые estimate, счётчики, материализованные view или кэш. Подробнее здесь — Как СУБД выполняет запрос.
Вопрос. Пароль postgres в docker-compose в открытом виде — "локально же".
Ответ. Compose-файл часто попадает в Git; секреты — через env/secrets, даже для dev. Подробнее здесь — СУБД в экосистеме, Конфигурации и данные.
Вопрос. Реплика "есть", но после падения master данные не сходятся.
Ответ. Асинхронная репликация даёт lag; failover без promote/consensus теряет последние транзакции. Планируйте RPO и тестируйте switchover. Подробнее здесь — Опорные темы.
Вопрос. Шардинг "на будущее" на старте — три пустых кластера.
Ответ. Шардинг усложняет JOIN и транзакции; нужен при реальном пределе одного сервера. Сначала индексы, партиции, read replica. Подробнее здесь — Опорные темы, Как СУБД выполняет запрос.
Вопрос. VIEW "медленный" — каждый раз пересчитывает JOIN.
Ответ. Обычное view — сохранённый запрос, не кэш. Для тяжёлых отчётов — materialized view + refresh. Подробнее здесь — Теоретические основы.
Вопрос. DBA говорит "обновите статистику" — зачем, если данные те же?
Ответ. Оптимизатор опирается на гистограммы и cardinality; после bulk load план устаревает. ANALYZE обновляет метаданные для выбора индекса. Подробнее здесь — Как СУБД выполняет запрос.
Вопрос. ACID "включён" — но transfer денег частично прошёл при сбое.
Ответ. Две отдельные autocommit-операции без явной транзакции — половина на счёте. Оберните debit+credit в BEGIN…COMMIT. Подробнее здесь — Конкурентный доступ, Теоретические основы.
Вопрос. Поле created_at хранится строкой "31.12.2024" — сортировка ломается.
Ответ. Даты храните в типе DATE/TIMESTAMP/TIMESTAMPTZ, не в VARCHAR. Строковая сортировка ≠ хронологическая. Подробнее здесь — Entity Relationship.
Вопрос. "NoSQL не нужна схема" — в проде 50 версий документа.
Ответ. Гибкая схема ≠ отсутствие контракта. Валидация на приложении, schema registry, миграции документов. Подробнее здесь — Знакомство с базами данных.
Вопрос. ER-диаграмма нарисована, а в SQL забыли FK — "потом добавим".
Ответ. Без FK целостность только в коде — гарантий нет. DDL с constraints сразу; отложенные FK допустимы для seed, потом ENABLE. Подробнее здесь — Entity Relationship.
Вопрос. Кодда 12 правил — PostgreSQL "не реляционная"?
Ответ. Правила — ориентир строгости; реальные СУБД частично отступают (например процедурное расширение). PostgreSQL — реляционная с расширениями. Подробнее здесь — Двенадцать правил Кодда.
Вопрос. Буферный пул 90 % RAM — OOM на сервере с PostgreSQL.
Ответ. shared_buffers и OS cache нужно балансировать с приложениями на той же машине. Тюнинг — не "всё в БД". Подробнее здесь — СУБД в экосистеме.
Вопрос. Аналитик просит "выгрузить всю БД в Excel" каждую неделю.
Ответ. Это нагрузка и риск утечки; лучше view, BI-инструмент или реплика для отчётов. Data governance фиксирует, кто и что читает. Подробнее здесь — Data Governance, Роль базы данных в организации.
Вопрос. Что такое база данных простыми словами?
Ответ. Организованное хранилище данных с правилами целостности, доступом многих пользователей и языком запросов. Управляет СУБД. Подробнее здесь — Знакомство с базами данных.
Вопрос. SQL vs NoSQL — что выбрать для проекта?
Ответ. SQL — связи, транзакции, отчёты. NoSQL — гибкая схема, горизонтальный scale, специфичные модели (документ, key-value). Часто оба. Подробнее здесь — Знакомство с базами данных, NoSQL.
Вопрос. Что такое первичный ключ (primary key)?
Ответ. Столбец или набор столбцов, уникально идентифицирующий строку. Не NULL, не дублируется. Подробнее здесь — Entity Relationship.
Вопрос. Внешний ключ (foreign key) — зачем нужен?
Ответ. Связывает строку с родительской таблицей, обеспечивает referential integrity. ON DELETE CASCADE/RESTRICT задаёт поведение при удалении. Подробнее здесь — Entity Relationship.
Вопрос. PostgreSQL vs MySQL — в чём разница?
Ответ. Оба реляционные; PostgreSQL сильнее в расширениях, JSON, строгости SQL; MySQL — распространён в LAMP, варианты движков. Выбор — под нагрузку и команды. Подробнее здесь — СУБД в экосистеме, PostgreSQL.
Вопрос. Что такое ACID в базах данных?
Ответ. Atomicity, Consistency, Isolation, Durability — гарантии транзакции: всё или ничего, согласованное состояние, изоляция параллельных сессий, сохранность после commit. Подробнее здесь — Конкурентный доступ, Теоретические основы.
Вопрос. Что такое индекс в базе данных и зачем он нужен?
Ответ. Дополнительная структура (часто B-tree) для быстрого поиска по столбцу без полного scan. Замедляет INSERT/UPDATE. Подробнее здесь — Как СУБД выполняет запрос.
Вопрос. ER-диаграмма — как нарисовать связи 1 к многим?
Ответ. Сущности — прямоугольники, связь — линия с кардинальностью 1 и N; в SQL — FK на стороне "много". Подробнее здесь — Entity Relationship.
Вопрос. Нормализация базы данных — что это?
Ответ. Разбиение таблиц, чтобы убрать дубли и аномалии при UPDATE (1НФ–3НФ). Подробнее здесь — Нормализация.
Вопрос. Что такое JOIN в SQL?
Ответ. Объединение строк из таблиц по условию связи (обычно FK). INNER, LEFT, RIGHT — разные правила включения. Подробнее здесь — SQL, Entity Relationship.
Вопрос. MVCC в PostgreSQL — что это?
Ответ. Multi-Version Concurrency Control: читатели не блокируют писателей, версии строк и vacuum. Подробнее здесь — Конкурентный доступ.
Вопрос. WAL в PostgreSQL — зачем журнал?
Ответ. Write-Ahead Log: изменения сначала в журнал, потом на диск — durability и point-in-time recovery. Подробнее здесь — Восстановление после сбоя, Теоретические основы.
Вопрос. Чем БД отличается от СУБД?
Ответ. БД — данные + схема. СУБД — программа (PostgreSQL, MySQL), которая ими управляет: SQL, транзакции, права. Подробнее здесь — Знакомство с базами данных.
Вопрос. MongoDB — это база данных или СУБД?
Ответ. Документная СУБД (NoSQL): JSON-подобные документы, гибкая схема, свой язык запросов. Подробнее здесь — Знакомство с базами данных, NoSQL.
Вопрос. Как ускорить медленный SQL запрос?
Ответ. EXPLAIN/ANALYZE, индексы на WHERE/JOIN, актуальная статистика, убрать SELECT *, переписать подзапрос. Подробнее здесь — Как СУБД выполняет запрос.
Вопрос. Что такое транзакция в SQL?
Ответ. Группа операций BEGIN … COMMIT/ROLLBACK как одно целое. Перевод денег — классический пример. Подробнее здесь — Конкурентный доступ.
Вопрос. Репликация базы данных — что это?
Ответ. Копия данных на реплике для чтения или failover. Синхронная/асинхронная — компромисс lag vs надёжность. Подробнее здесь — Опорные темы.
Вопрос. Шардинг vs партиционирование — в чём разница?
Ответ. Партиции — части одной логической таблицы в одной СУБД. Шардинг — данные на разных серверах по ключу. Подробнее здесь — Как СУБД выполняет запрос, Опорные темы.
Вопрос. SQLite — можно ли использовать в production?
Ответ. Для встраивания, мобильных, low-traffic — да. Для высокой конкурентной записи web-backend — PostgreSQL/MySQL. Подробнее здесь — СУБД в экосистеме, SQLite.
Вопрос. Что такое схема базы данных?
Ответ. Описание таблиц, столбцов, ключей и ограничений — логическая структура. В PostgreSQL schema также namespace (public). Подробнее здесь — Знакомство с базами данных.
Вопрос. NULL в SQL — что означает?
Ответ. "Значение неизвестно / не применимо", не ноль и не пустая строка. Проверка через IS NULL, не = NULL. Подробнее здесь — Теоретические основы.
Вопрос. Как спроектировать базу данных для интернет-магазина?
Ответ. Сначала ER: пользователи, товары, заказы, позиции, оплаты; кардинальности, ключи, потом DDL. Подробнее здесь — Entity Relationship, Проектирование БД.
Вопрос. Backup и restore PostgreSQL — с чего начать?
Ответ. pg_dump, регулярные бэкапы + архив WAL для PITR. RPO/RTO задают политику. Подробнее здесь — Восстановление после сбоя, Управление РСУБД.
Что запомнить
Базы данных — это строго организованные хранилища информации, управляемые специализированными системами. Они обеспечивают целостность, безопасность, производительность и надёжность хранения данных, позволяя приложениям работать с огромными объёмами информации без потерь и ошибок.
Мы рассмотрели ключевые понятия:
- Сущность — объект реального мира, описываемый в системе (например, "Пользователь", "Заказ").
- Атрибут — характеристика сущности, реализуемая как поле в таблице.
- Связь — взаимодействие между сущностями, выраженное через внешние ключи и семантические глаголы.
- ER-модель — концептуальная схема, отражающая структуру предметной области до реализации.
- СУБД — программная система, управляющая созданием, хранением, обработкой и защитой данных.
- Реляционные и нереляционные модели — два основных подхода к организации данных, каждый со своими сценариями применения.
- Физическое устройство БД — данные хранятся на диске в виде байтов, организованных в страницы, экстенты и файлы; работа с ними оптимизируется через буферный пул, индексы и статистику.
- Архитектура ANSI/SPARC — трёхуровневая модель (внешний, концептуальный, внутренний), обеспечивающая логическую и физическую независимость данных.
- Оптимизация запросов — зависит от селективности, статистики, индексных структур и правильного построения связей.
- Двенадцать правил Кодда — ориентир, насколько продукт следует реляционной модели (глава 5).
- Конкурентный доступ — блокировки, MVCC, оптимистичный контроль (глава 7).
- Восстановление после сбоя — WAL, redo/undo; отличие от бэкапа (глава 8).
- Роль БД в организации — жизненный цикл модели, люди, внедрение (глава 6).
Проектирование баз данных начинается с понимания бизнес-логики, а не с выбора СУБД или синтаксиса SQL. Углублённый маршрут — Проектирование баз данных. Только после чёткого определения сущностей, их атрибутов и связей можно переходить к технической реализации. При этом важно соблюдать принципы нормализации, избегать избыточности и обеспечивать масштабируемость через партиционирование, индексацию и грамотное физическое размещение.
Наконец, база данных — это живая система, требующая постоянного мониторинга, актуализации статистики, обслуживания индексов и резервного копирования. Её эффективность напрямую влияет на производительность всего приложения.
Куда идти дальше
Полный маршрут — на странице о разделе.
Проверьте себя: Чек-лист самопроверки.