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

В любой системе данных гораздо больше, чем видно на экране: за одним заказом в интернет-магазине стоят клиент, состав, адрес, статусы, платежи, история изменений, и всё это должно храниться годами, обновляться десятками людей и находиться за доли секунды. Место, где система всё это хранит, называется базой данных, и вокруг него крутится половина вопросов в постановках, тестах, отчётах и инцидентах. Разберёмся, чем база отличается от файла и таблицы Excel, какие базы бывают и кому в команде она нужна, кроме разработчика.

Кейс: кнопка «Оформить»

Клиент интернет-магазина собрал корзину и нажал «Оформить заказ». Что происходит с этим заказом дальше?

В ближайшие сутки заказ понадобится пяти разным людям в пяти разных ролях. Складу - чтобы прочитать состав и собрать коробку. Курьеру - чтобы поставить статус «доставлен». Поддержке - чтобы найти заказ по номеру, когда клиент позвонит. Финансам - чтобы в конце месяца посчитать выручку. И самому клиенту - чтобы посмотреть, где посылка.

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

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

Почему не Excel

Первое возражение, которое возникает у любого, кто работал в офисе: всё это можно хранить в таблице Excel или Google Sheets. Столбцы - поля, строки - заказы, фильтр - поиск. И это правда: таблица прекрасно хранит данные, пока она остаётся рабочим файлом. Проблемы начинаются, когда файл или общую таблицу пытаются сделать основным источником данных для системы, с которой работают десятки людей и другие программы.

Первая проблема - одновременная работа. Оператор поддержки открыл файл и правит адрес доставки, курьер в это же время ставит статус. Кто сохранил последним, тот и прав: чужие изменения затёрты, и никто об этом не узнает. База данных устроена иначе: СУБД заметит, что двое меняют одну и ту же запись, а не молча возьмёт последнюю версию. Как именно - в статье про транзакции.

Вторая - целостность. В колонке «Клиент» в Excel можно написать что угодно: опечатку в фамилии, пустоту, номер клиента, которого не существует. База умеет это запрещать: нельзя создать заказ и сослаться на клиента, которого нет в таблице клиентов. Это свойство называется ссылочной целостностью, и в статьях про ERD оно станет главным героем.

Третья - поиск и объём. Миллион строк в Excel - это файл, который открывается минуту и ещё минуту фильтруется. База находит нужную запись среди миллионов быстро - не сама по себе, а потому что для частых поисков в ней создают индексы. Как они работают - чуть ниже.

Четвёртая - надёжность. Файл лежит на чьём-то ноутбуке. Ноутбук упал, файл случайно перезаписан, версия от вторника потеряна. База ведёт журнал каждой операции, делает резервные копии и умеет восстановиться после сбоя в состояние на секунду до него.

Ни одна из четырёх проблем не про «хранить». Хранить умеет и Excel. Все четыре - про то, что происходит вокруг хранения, когда данными пользуются много людей и систем. Ради этого «вокруг» базы данных и существуют.

База данных, СУБД и SQL

Три слова, которые в разговоре легко сливаются в одно, стоит развести сразу.

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

Четыре глагола

Если убрать технические детали, база данных умеет четыре вещи, и любое требование к данным сводится к одной из них.

Хранить, но структурно. У каждого заказа одни и те же поля: номер, клиент, сумма, статус, дата. Для каждого поля можно задать, обязательно оно или нет: сумму у заказа пропустить нельзя, а комментарий - можно. Когда в постановке появляется фраза «у заказа появляется поле “способ оплаты”», это изменение структуры хранения, и оно затрагивает все существующие заказы: что будет в этом поле у тех, что оформлены вчера?

Находить - по любому полю, а быстро - по тем, под которые есть индексы. Индекс - это отдельный указатель «значение → где лежит запись»: с ним СУБД прыгает сразу в нужное место, а без него читает таблицу строка за строкой.

«Все заказы клиента 17 за март со статусом “отменён”» - один запрос, и если поля в нём проиндексированы, ответ приходит быстро даже на миллионах заказов. Требование к отчёту или к поиску в админке - это, по сути, описание того, по каким полям система должна уметь находить.

Связывать - одна запись ссылается на другую. Заказ ссылается на клиента, строка заказа - на товар. Это то, что рисуют в ERD, и то, что делает базу базой, а не набором табличек.

Защищать - от потери, от противоречий, от чужих глаз. Нельзя удалить клиента, у которого есть заказы, пока не решено, что делать с заказами. Нельзя записать отрицательное количество. Нельзя оператору поддержки видеть номер карты. Часть этих правил живёт в самой базе, часть - в приложении, и понимать, где какая, важно всем, кто пишет требования или проверяет их.

Какие бывают базы

Первое деление - на реляционные и нереляционные. Второе, внутри нереляционных - по тому, ради какой задачи от реляционной модели отказались.

Реляционные базы хранят данные в таблицах со строками и столбцами, таблицы связаны между собой ссылками, а работают с ними через язык SQL. Их главное свойство - одна модель на любую предметную область: заказы, клиенты, платежи, учёт, всё, где важны связи и целостность, живёт здесь. В большинстве корпоративных систем основная база - реляционная, и весь блок про ERD в этом разделе именно про них.

Нереляционные базы (их ещё называют NoSQL) - это не «лучше» и не «новее». Каждая из них жертвует чем-то из реляционной модели ради одной конкретной задачи.

• Документные хранят каждую запись как документ произвольной структуры со своим набором полей. Удобно для карточек товаров, где у ноутбука есть «объём памяти», а у футболки - «размер».
• «Ключ - значение» держат данные в памяти и отдают их по ключу за микросекунды. Сессии пользователей, кэш, счётчики, очереди.
• Колоночные хранят данные по столбцам, а не по строкам, и за счёт этого считают отчёты по миллиардам записей за секунды. Аналитика, логи, витрины данных.
• Графовые делают связи первичными объектами и нужны там, где вопрос звучит как «кто с кем связан через кого». Рекомендации, антифрод, социальные связи.

В одной системе обычно живёт несколько баз разных типов: заказы - в реляционной, сессии - в «ключ - значение», отчёты - в колоночной. Конкретные системы каждого типа, в том числе российские, и то, как между ними выбирают, разберём в отдельных статьях раздела.

Где база встречается в работе

База данных - не только территория разработчика. Одна и та же база отвечает на разные вопросы в зависимости от того, кто спрашивает.

• Аналитик переводит задачу «добавить оплату по QR-коду» на язык базы: новые поля в существующем платеже или новая таблица? Что будет с историей операций? Какие поля обязательны?
• Разработчик решает, как это хранить, как связать с существующими данными, как быстро находить и как не потерять при сбое.
• Тестировщик после проверки на экране заглядывает в базу: что реально записалось и совпадает ли это с тем, что показал интерфейс.
• DBA или DevOps отвечают за то, чтобы база жила: резервные копии, доступы, нагрузка, восстановление после сбоя.
• Продакт или менеджер отвечает на вопрос «сколько клиентов бросают корзину на этапе доставки» одним запросом, вместо того чтобы неделю ждать отчёт.
• Поддержка, получив «у клиента пропал заказ», различает три причины: заказ удалён, сменил статус и скрылся из списка, потерял связь с клиентом. У каждой своё исправление.
• Финансы берут выручку за месяц по регионам из базы, а не из чьего-то файла.

Вопрос у каждого свой, а база одна, и чем лучше каждый понимает, что в ней есть и как оно связано, тем меньше вопросов приходится задавать разработчику.

Итог

База данных нужна не потому, что данных много, а потому, что с ними работают многие: люди и системы, одновременно, с разными целями. Отсюда следуют все её свойства. Она защищает от потерянных правок, потому что правят одновременно. Следит за целостностью, потому что вводят разные люди. Находит быстро, потому что записей миллионы. Не теряет, потому что цена потери - чужая работа. Файл и Excel решают задачу «сохранить», база - задачу «сохранить так, чтобы этим можно было пользоваться вместе».

Отсюда же следует, что база - общая территория. Разработчик выбирает, как хранить, но что хранить, что обязательно и что делать со старыми записями при каждом изменении - это вопросы, на которые отвечает команда целиком.

Что дальше

В этой статье мы несколько раз сказали, что реляционная база хранит данные в связанных таблицах, и ни разу не объяснили, что это значит на деле. Почему заказ и клиент - это две таблицы, а не одна большая? Как одна строка «знает» о другой? Что база делает, когда кто-то пытается удалить клиента с заказами? Следующая статья, «Реляционная модель простыми словами», отвечает на эти вопросы на тех же заказах и клиентах: таблицы, строки, столбцы, ключи и то самое правило целостности, которое отличает базу от Excel.

Источники

• E. F. Codd, «A Relational Model of Data for Large Shared Data Banks» (1970) - исходная работа о реляционной модели.
• Документация PostgreSQL, ClickHouse, Redis, MongoDB - разделы «About».