Что такое база данных и зачем она нужна

С чего мы начинаем и куда придём

Привет. Это самый первый урок курса «SQL для начинающих». Прежде чем учиться разговаривать с базой данных на её языке, полезно понять, с чем вообще мы будем разговаривать. Что такое база данных, чем она отличается от обычного файла, почему программисты, аналитики, бухгалтеры и админы так с ней носятся и почему её нельзя просто заменить большим Excel-документом на сетевом диске.

В этом уроке — никакого SQL. Ни одной команды, ни одного ключевого слова. Сегодня собираем интуицию: что это за зверь, зачем он нужен и где живёт. На следующем уроке начнём смотреть, как реляционная база данных устроена внутри. А ещё через урок — впервые «заговорим» с ней.

Договоримся сразу: я буду писать «БД» как сокращение от «база данных». Так короче и привычнее.

База данных простыми словами

Самое короткое определение даёт MDN: «база данных — это система хранения, которая собирает упорядоченные данные, чтобы их было проще искать, структурировать и расширять». Переведём на человеческий: это место, где данные лежат не как попало, а по правилам, и оттуда их легко достать.

Аналогия номер один — школьная тетрадь по словарю. Слова в ней не разбросаны по случайным страницам. Они сгруппированы, отсортированы, у каждой записи есть одно и то же поле «слово», «перевод», «пример». Если завтра ты захочешь добавить новое слово — ты знаешь, куда его записать. Если захочешь найти старое — знаешь, где искать. Это и есть «упорядоченные данные».

Аналогия номер два — Excel. Открыл файл, видишь сетку, в каждой ячейке какое-то значение, можно отсортировать, можно отфильтровать. БД — это идеологически тот же подход, только на стероидах: с защитой от ошибок, с одновременным доступом, с поиском среди миллиардов записей и с гарантиями, которых у Excel нет.

Аналогия номер три — каталог в библиотеке. Где-то на полках стоят сами книги (это «данные»). А в каталоге аккуратно записано, какая книга где лежит, кто её взял, когда вернёт. Без каталога тебе пришлось бы обходить все полки руками. Каталог — и есть БД, которая делает данные находимыми.

Если совсем коротко: БД — это «организованная коллекция данных, спроектированная так, чтобы с ней было удобно и безопасно работать программам и людям». Слово «организованная» здесь ключевое.

База данных и СУБД — разводим путаницу сразу

В разговорах ты будешь слышать два слова, которые часто путают: база данных и СУБД (по-английски DBMS, Database Management System). Давай раз и навсегда.

База данных — это сами данные, организованные по определённым правилам. Можно представить как «склад». Wikipedia формулирует так: «организованная коллекция данных или тип хранилища данных, основанный на использовании системы управления базами данных» (Wikipedia).

СУБД — это программа, которая управляет складом. Принимает запросы, отдаёт результаты, следит, чтобы никто ничего не сломал, контролирует, кто что видит. По определению той же Wikipedia: «программное обеспечение, которое взаимодействует с конечными пользователями, приложениями и самой базой данных, чтобы захватывать и анализировать данные» (Wikipedia).

Примеры конкретных СУБД, которые встречаются на каждом шагу: PostgreSQL, SQLite, MySQL, MariaDB, Oracle, SQL Server. В этом курсе мы будем работать с PostgreSQL и SQLite — потому что они бесплатные, мощные и очень распространённые.

Самое важное: на практике слова «база данных» и «СУБД» часто используют как синонимы, и это нормально. Wikipedia честно об этом пишет: «из-за тесной связи между ними термин „база данных“ часто употребляют свободно, имея в виду и саму базу, и СУБД, которая ею управляет» (Wikipedia). Не пугайся, когда коллега скажет «у нас PostgreSQL как база» — он имеет в виду и движок, и данные сразу.

Почему не Excel и не текстовый файл

Логичный вопрос новичка: «У меня есть данные. Почему я не могу просто положить их в файл?» Отличный вопрос. Давай посмотрим, как обычно живут данные в простом файле.

Вот те же самые пользователи в формате CSV — это просто текст, где значения разделены запятыми:

id,name,email,joined
1,Алиса,alice@mail.com,2025-01-15
2,Боб,bob@mail.com,2025-02-03
3,Карина,karina@mail.com,2025-02-19
4,Денис,denis@mail.com,2025-03-04
5,Елена,elena@mail.com,2025-03-21

А вот те же данные в JSON — формате, который любят программисты:

[
  { "id": 1, "name": "Алиса",   "email": "alice@mail.com",   "joined": "2025-01-15" },
  { "id": 2, "name": "Боб",     "email": "bob@mail.com",     "joined": "2025-02-03" },
  { "id": 3, "name": "Карина",  "email": "karina@mail.com",  "joined": "2025-02-19" },
  { "id": 4, "name": "Денис",   "email": "denis@mail.com",   "joined": "2025-03-04" }
]

Выглядит безобидно. Пять записей. Можно открыть в редакторе, можно прочитать глазами. Но как только данные становятся настоящими — начинаются проблемы. Разберём шесть штук.

1. Целостность. В файле никто тебе не запретит написать joined: "вчера утром" или email: 12345. Программа, которая будет это читать, упадёт. БД заранее договорится с тобой о правилах: вот это число, вот это дата, вот это текст — и аккуратно отвергнет всё, что в правила не лезет. Сюда же относится загадочное слово ACID — это набор гарантий, что твои изменения либо применятся целиком, либо не применятся вовсе. Запомни его как метку, расшифровывать не будем — вернёмся к нему в одном из последних модулей курса. Пока достаточно знать: серьёзные БД, включая PostgreSQL и SQLite, ACID-совместимы; первая «ACID-совместима с 2001 года», вторая обещает «ACID-транзакции даже после потери питания».

2. Совместный доступ. Представь, что в команде из 50 человек все одновременно открыли один Excel-файл и начали его править. Половина изменений потеряется, кто-то увидит чужие правки только через час, кто-то перезапишет чужую работу. БД для этого и придумали: «сервер PostgreSQL может обрабатывать множество одновременных подключений от клиентов». Тысячи людей одновременно покупают билеты — БД сама разруливает, чтобы один и тот же билет не продали дважды.

Проверь себя: представь, что в команде из 50 человек все одновременно открыли один Excel-файл и начали править. Что произойдёт через час и почему БД эту проблему решает в принципе? Если можешь сформулировать своими словами — двигаемся дальше.

3. Поиск. В файле на миллион записей искать конкретного пользователя — это перечитать миллион записей. На миллиарде это уже не работает в принципе. БД умеет искать сразу в нужном месте, потому что заранее построила вспомогательные структуры. SQLite в документации прямо пишет, что «может быть быстрее файловой системы для чтения и записи на диск» — речь о маленьких порциях данных, но идея та же: правильно организованное хранилище экономит часы.

4. Структура и контроль. Когда данных много, легко получить кашу. У одного юзера поле называется email, у другого e-mail, у третьего mail. Кто-то написал имя, кто-то — никнейм, кто-то — два слова через запятую. БД заранее знает структуру и контролирует, что попадает внутрь. Wikipedia формулирует это как «создание, изменение и удаление организационных определений для структуры данных».

5. Безопасность и разграничение ролей. В файле либо у тебя есть доступ ко всему, либо нет. В БД можно сказать: «кассир видит только свои продажи за сегодня, директор видит всё, бухгалтер видит финансовые отчёты, но не видит клиентских данных». Это не теория — это стандартная функция СУБД (Wikipedia): «поддержка авторизации доступа и обновления данных».

6. Масштаб и надёжность. Excel начинает скрипеть на сотнях тысяч записей и ложится на миллионе. Серьёзная БД — нет. Документация PostgreSQL говорит без ложной скромности: «PostgreSQL доказал свою высокую масштабируемость как по объёму данных, так и по числу одновременных пользователей. В продакшене работают кластеры, управляющие многими терабайтами данных, а специализированные системы — петабайтами».

Возьмём пример из CSV выше. В файле имена и почты лежат рядом, без обещаний. Что мешает кому-то записать пятую строку с тем же email, что и у Алисы? Ничего. БД хранит те же сведения, но на входе спросит: «Уверен, что email уникален? Точно дата? Точно эта запись связана с тем-то?» — и не пустит лишнее. И всё это без потери скорости.

После такого разбора у тебя уже не должно быть вопроса «может, обойдёмся файлом». Иногда — да, обойдёмся. Если данных немного, пользователь один и потеря не страшна — JSON или CSV сойдёт. Как только появляется хоть один признак из шести выше — нужна БД.

Где базы данных живут (а они везде)

Можно подумать, что БД — это что-то «для серверов», далёкое от обычной жизни. На деле они окружают тебя плотнее, чем тебе кажется.

Банки и финтех. Каждый перевод, каждая операция по карте — это запись в БД. Тут особенно важна целостность: нельзя, чтобы у тебя деньги списались, а у получателя не пришли.

Соцсети и мессенджеры. Миллионы постов, лайков, комментариев в секунду. Всё это надо мгновенно находить — «покажи мне ленту друзей за сегодня». Без БД это физически невозможно.

Интернет-магазины. Каталог товаров, заказы, остатки на складе, история покупок, бонусные баллы. Когда ты обновляешь страницу с корзиной — за этим стоит запрос к БД.

Медицина и госуслуги. Карточки пациентов, записи к врачам, история приёмов. Здесь критична безопасность и аудит: кто и когда смотрел чьи данные.

Твой браузер прямо сейчас. Внутри почти каждого браузера, телефона и приложения работает SQLite — лёгкая встраиваемая СУБД. Документация SQLite спокойно сообщает: «SQLite — самая широко развёрнутая база данных в мире». История посещений, закладки, кеш — это файл SQLite на твоём диске.

Встроенные устройства. Документация SQLite перечисляет типичные места, где она работает: «мобильные телефоны, камеры, часы, автомобили, дроны, медицинские устройства». Если у тебя есть умные часы — внутри почти наверняка крутится БД.

Запомни ощущение: БД — это не про «большие энтерпрайз-системы». БД — это про любое приложение, которое хочет надёжно помнить.

Какие бывают базы данных

Большая семья БД делится на два больших лагеря.

Реляционные (SQL). Это «классика». Данные хранятся структурированно, связи между ними строго описаны, общаются с такой БД на языке SQL. MDN говорит прямо: «большинство баз данных в веб-разработке используют реляционную СУБД для организации данных и SQL для программирования. Примеры — MySQL (или MariaDB), SQL Server, Oracle Database». Сюда же — PostgreSQL и SQLite. Этому семейству и посвящён весь наш курс.

NoSQL. Это «всё остальное» — БД, которые специально устроены не как реляционные. Wikipedia объясняет (Wikipedia): NoSQL (изначально — «not only SQL» или «non-relational») «обозначает тип проектирования БД, который хранит и извлекает данные иначе, чем традиционная структура реляционных БД». В этом лагере живут разные подвиды: key-value (Redis — «ключ → значение»), document (MongoDB — данные в документах, похожих на JSON), graph (Neo4j — про связи вроде «кто кому друг»), wide-column (Cassandra — для огромных объёмов с предсказуемыми запросами). MDN добавляет: «некоторые БД не следуют реляционному механизму и называются NoSQL. Примеры — MongoDB, Cassandra, Redis».

Что из этого важно тебе сейчас. Реляционные БД и SQL — самый распространённый, проверенный временем подход, и для большинства задач это правильный первый выбор. NoSQL — другое семейство со своими сильными сторонами; в курсе мы его не разбираем, но знать о его существовании полезно: на собеседованиях и в продакшене ты с этими названиями ещё встретишься.

Проверь себя: если друг говорит «мы храним пользователей в Redis» — это реляционная БД или нет? А MySQL? А MongoDB? Если можешь ответить навскидку — отлично, материал зашёл.

Что взять с собой

База данных — это не магия и не просто «большой файл». Это организованное хранилище данных, спроектированное под поиск, надёжность и одновременный доступ.
БД и СУБД — это разные вещи: данные и программа, которая ими управляет. Но в живой речи их часто путают, и это нормально.
Файл (Excel, CSV, JSON) хорош для маленьких задач. БД нужна, когда данных много, пользователей много или ошибки дорого стоят.
Шесть причин, почему БД лучше файла: целостность, совместный доступ, быстрый поиск, структура, безопасность, масштаб.
Реляционные БД (PostgreSQL, SQLite, MySQL) — то, что мы будем учить весь курс. NoSQL (MongoDB, Redis) — соседи по индустрии, но не наша тема.

Что дальше

Сейчас ты понимаешь, зачем нужна БД и почему её не заменишь файлом. Но мы пока ни слова не сказали о том, как именно реляционная БД организует данные внутри. Чем «организованно» отличается от «как попало»? Откуда берутся гарантии, что email уникальный, а дата — это точно дата?

Об этом — следующий урок: «Реляционная модель». Там мы впервые познакомимся с тем, как PostgreSQL и SQLite раскладывают данные по полочкам, и узнаем, как называются эти «полочки». А ещё через урок — впервые попросим у БД что-нибудь на её родном языке.

До встречи в уроке 1-2.

Что такое база данных и зачем она нужна