С нуля: что такое база данных на самом деле
База данных — надёжное структурированное хранилище, в которое пишет приложение и которое переживает перезапуски. Это карта «с нуля» и восемь слов, которые каждый senior-юнит считает уже знакомыми.
Приложение записывает пользователя в память: const user = { id: 1, name: "Alice" }. Ты перезапускаешь сервер — и Алисы больше нет. Добавляешь файл — Алиса переживает перезапуск, но найти её по имени без чтения каждого байта нельзя. Добавляешь второй файл для заказов — и уже непонятно, какой заказ чей. Каждое приложение, работающее с настоящими данными, упирается в одни и те же три стены: данные пропадают, поиск медленный, связи между объектами ломаются. База данных существует, чтобы снести все три стены сразу — надёжно, быстро и корректно — и позволить тебе думать о продукте, а не о трубах хранилища.
Единственная проблема, которую решает база данных
Когда программа хранит данные только в памяти, они исчезают при завершении процесса. Когда она хранит данные в плоских файлах, поиск означает чтение всего, а связь двух файлов (пользователи и заказы) требует самодельного кода, который ломается при любом изменении формата. База данных решает обе проблемы одним ходом: пишет данные на диск в структурированном виде и хранит описание этой структуры — так что любая программа, говорящая на одном языке (SQL — Structured Query Language, язык структурированных запросов), может найти, объединить и изменить данные, не зная, как байты расположены физически.
Когда в production начинает тормозить страница и ты начинаешь искать причину, ответ почти всегда ведёт к базе данных — а значит, понимать её строительные блоки не просто полезно, а необходимо.
Эта единственная идея — структурированное, надёжное, запрашиваемое хранилище — это то, на чём строятся все senior-юниты. Всё остальное — оптимизация или компромисс поверх неё.
Восемь слов, которые остальной трек считает знакомыми
Когда ты дойдёшь до юнитов про MVCC (механизм многоверсионного управления параллелизмом), внутреннее устройство индексов или уровни изоляции транзакций — ни один из них не остановится на этих основах. Они будут считать, что ты уже несёшь их с собой. Вот они, по одному предложению — что это и зачем оно.
| Слово | Что это | Зачем оно |
|---|---|---|
| Таблица (table) | Именованная сетка строк и столбцов, у всех одинаковая форма. | Чтобы данные одного вида жили вместе и их можно было искать как единое целое. |
| Строка и столбец (row, column) | Строка — одна запись (один пользователь, один заказ); столбец — один атрибут каждой записи (name, created_at). | Чтобы у каждого факта было фиксированное место — всегда знаешь, куда смотреть. |
| Первичный ключ (primary key) | Столбец (или набор столбцов), значение которого уникально для каждой строки таблицы. | Чтобы любую строку можно было назвать однозначно — это уникальный ID на уровне базы. |
| Внешний ключ (foreign key) | Столбец, хранящий первичный ключ строки из другой таблицы. | Чтобы две таблицы были связаны — и база отказывалась создавать заказ для несуществующего пользователя. |
| SQL / запрос (query) | Язык предложений (SELECT, INSERT, UPDATE, DELETE), которые отправляют базе, чтобы читать или менять данные. | Чтобы любая программа могла общаться с базой, не зная, как данные хранятся на диске. |
| Индекс (index) | Отдельная структура данных (обычно B-дерево), которую база ведёт рядом с таблицей. | Чтобы поиск строк по значению столбца занимал миллисекунды, а не чтение всей таблицы. |
| Транзакция (transaction) | Группа изменений, которые либо все вместе успешно фиксируются, либо все вместе отменяются. | Чтобы сбой посередине операции не оставил данные наполовину изменёнными — деньги уходят с одного счёта только если приходят на другой. |
| Схема (schema) | Чертёж, определяющий, какие таблицы существуют, какие у них столбцы и какие ограничения действуют. | Чтобы база отвергала плохие данные до того, как они сохранены, а не после того, как они вызвали баг. |
Как они складываются вместе
Прочитанные по порядку, слова рассказывают одну историю: данные живут в таблицах из строк и столбцов; первичный ключ даёт каждой строке уникальное имя; внешний ключ в одной таблице ссылается на первичный ключ другой, связывая их; данные запрашивают с помощью SQL; индекс делает запрос быстрым, позволяя базе сразу прыгнуть к нужным строкам вместо полного сканирования; транзакция оборачивает многоступенчатое изменение, делая его атомарным; а схема объявляет правила, удерживающие всю структуру вместе. Этот абзац — весь трек по базам данных в миниатюре; каждый следующий юнит приближает одну из этих идей.
▸Почему это работает
Почему не просто использовать JSON-файлы на диске, как раньше? Потому что у файлов нет схемы, нет языка запросов, нет индексов и нет транзакций. Как только два пользователя пишут одновременно — получаешь повреждение; как только данных становится больше нескольких мегабайт — сканируешь каждый байт ради одной записи; как только связываешь два файла руками — получаешь оборванные ссылки. Базы данных существуют, чтобы решить все четыре проблемы — структура, скорость, параллелизм и корректность — как единое целое, а не оставлять каждую из них залатывать прикладному коду.
Это не нужно зубрить
Две честные ремарки перед восхождением. Первая: никто не интернализирует все восемь слов в первый день — ты встретишь каждое снова в своём юните с настоящими запросами и реальными историями об отказах, и тогда оно уляжется. Эта страница — вешалка для деталей, а не экзамен. Вторая: не каждому приложению одинаково нужны все восемь возможностей. Крошечный read-heavy сервис может работать без единой транзакции. Senior-трек учит полной картине, потому что этого требуют production-системы, — но «понимай инструмент, тянись к нему когда заболит» и есть senior-инстинкт.
Какие три проблемы решает база данных, с которыми не справляются плоские файлы на диске?
Расставь путь от сырых данных до корректного быстрого результата запроса:
- 1 Схема определяет таблицы, столбцы и ограничения, которые база будет соблюдать
- 2 Строки вставляются; первичные и внешние ключи связывают их между таблицами
- 3 Строится индекс, чтобы база могла быстро прыгать к нужным строкам
- 4 Приходит SQL-запрос; база возвращает корректный результат за миллисекунды
- 01В одном дыхании: какую проблему решает база данных и в чём ядро техники?
- 02Проследи путь от пустой базы данных до корректного результата запроса, называя каждую часть.
База данных — это одна идея с кучей навешанной механики: хранить данные живыми в структурированной форме, которую любая программа может запросить и изменить безопасно, даже спустя долгое время после завершения процесса, который их записал. Структурная половина — это схема, чертёж таблиц, строк, столбцов и ограничений, позволяющий базе отвергать плохие данные до их сохранения. Запрашиваемая половина — SQL, язык, работающий независимо от того, как байты расположены на диске. Связующая половина — ключи: первичный ключ даёт каждой строке уникальное имя; внешний ключ в одной таблице указывает на первичный ключ другой, и база отказывается создавать висячие ссылки. Быстрая половина — индекс, B-tree-ярлык, превращающий полные сканирования таблиц в поиск за миллисекунды. Корректная половина — транзакция: группа изменений «всё или ничего», чтобы сбои не оставляли данные наполовину обновлёнными. Тебе не нужно держать все восемь слов сразу — у каждого впереди свой юнит. Дальше: Unit 01, реляционная модель — таблицы, ключи, ограничения и когда стоит отступить от правил. Теперь, когда в логе ошибок или на код-ревью встретится «foreign key constraint» или «index scan» — ты будешь знать, какой именно строительный блок говорит с тобой и в каком юните искать ответ.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.
Примени это
Примени этот урок в реальном проекте.