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

База данных — упорядоченное хранилище под присмотром программы-сторожа, СУБД. Реляционная база хранит данные в таблицах, связанных ключами.

Где живут данные сайта

Сайт из одних HTML-файлов хранит всё в самой разметке: хотите поменять цену, откройте файл и поправьте. Пока правок мало и делает их один человек, это отличная жизнь (на статических сайтах так и живут, об этом в части 8). Но как только данные начинают меняться часто или приходить от посетителей, их нужно куда-то записывать и откуда-то читать: заявки из формы, заказы, записи на приём, комментарии.

Самое простое место для них это файл: текстовый, CSV или JSON (его мы разбирали в части 5). Любая программа может открыть файл, прочитать, изменить и записать. На маленьком сайте с одним редактором этого хватит. Давайте посмотрим, где начинаются неприятности.

Когда файла уже мало

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

Файл на диске База данных

Редактор A ещё не читал

Файл 10 свободных мест

Редактор B ещё не читал

Шаг 1 из 5. В файле написано: свободных мест на вашу услугу — 10.

Файл просто лежит на диске. Он не знает, что его будут править двое.

Назад Дальше Сначала

Текстовая альтернатива: в файле два редактора прочитали 10, оба записали 9, и одна заявка потерялась. В базе данных второй редактор ждёт, пока первый подтвердит правку, читает уже 9 и записывает 8: обе правки сохранены. Числа в схеме придуманы.

В этом примере файл потерял одну правку и даже не заметил. Но это только первая из бед. Вот все пять, которые заставляют переходить с файлов на базы данных.

1. Одновременные правки. Показано выше: последняя запись затирает предыдущую.
2. Целостность. В файле услуг у каждой есть «категория» из другого файла. Кто-то удалил категорию, а услуги на неё остались. Файл не заметит.
3. Поиск. Чтобы найти заявки за вчера, файл придётся прочитать целиком. На десяти заявках это незаметно, на миллионе ощутимо.
4. Права. Файл читает и меняет кто угодно с доступом к нему. Хочется иначе: редактор правит услуги, бухгалтер читает заявки, посетитель не видит ничего.
5. Сбои. Если сервер выключился посреди записи, файл останется записанным наполовину.

Все пять проблем решает один инструмент.

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

База данных это упорядоченное хранилище, за которым присматривает специальная программа. Такая программа называется СУБД, система управления базами данных. Слова «база данных» часто говорят про обе вещи сразу: PostgreSQL, MySQL и SQLite это СУБД, а то, что в них лежит, это базы.

Что делает СУБД, чего не делает файл:

• Не даёт двум правкам затереть друг друга. Для этого есть блокировки и транзакции (о них в уроке 4).
• Проверяет правила. «Это поле не может быть пустым», «такой номер уже есть», «ссылаться можно только на существующую категорию».
• Быстро ищет, потому что умеет строить подсказки для поиска, индексы (тоже урок 4).
• Раздаёт права: кто что может читать и менять.
• Переживает сбои. Если питание пропало на середине записи, после запуска данные либо старые целиком, либо новые целиком.

Заметьте, что СУБД не обязательно большая и далёкая. SQLite это база данных, которая лежит в одном файле и работает прямо внутри программы, без отдельного сервера. Она стоит в вашем телефоне и в браузере. Автор SQLite так и пишет: она подходит для сайтов с умеренной нагрузкой, а для сотен одновременных записей лучше сервер вроде PostgreSQL. Поэтому «файл против базы» это не вопрос расположения: это вопрос, есть ли сторож.

Проверьте себя: чем SQLite в одном файле отличается от JSON-файла?

Внутри SQLite работает программа-сторож: она проверяет правила, блокирует одновременные записи, умеет искать по индексам и доводит запись до конца, даже если питание пропало. JSON-файл ничего этого не делает, он просто текст.

Таблицы, строки и столбцы

Самый распространённый вид баз данных называется реляционным (от английского relation, отношение). В нём все данные лежат в таблицах. Таблица выглядит как знакомая электронная таблица, но строже.

id	title	price	category_id
1	Первая услуга	3000	1
2	Вторая услуга	5000	1
3	Третья услуга	1500	2

• Таблица хранит однотипные записи (все услуги).
• Строка это одна запись: одна услуга со всеми значениями.
• Столбец это одно поле каждой записи, и у него есть тип: число, текст, дата, да/нет. База не даст записать в «цену» слово «договорная». Это главное отличие от ячейки Excel, в которую можно вписать что угодно.

Первичный ключ это столбец, значение которого однозначно называет строку и никогда не повторяется. Обычно это число id, которое база выдаёт сама. Почему не название? Его могут исправить, и тогда все ссылки на строку сломаются; к тому же две услуги могут называться одинаково. А номер ничего не значит и потому не меняется.

Внешний ключ это столбец, который хранит ключ строки из другой таблицы. В примере category_id указывает на строку таблицы категорий. Так таблицы связываются (отсюда «реляционные»: связанные). И база следит за тем, чтобы ссылка не вела в пустоту.

Связи бывают трёх видов, и все три вы встретите в своём проекте:

• Один ко многим: у одной категории много услуг, а услуга в одной категории. Внешний ключ стоит на стороне «многих».
• Многие ко многим: у человека много услуг, и у услуги может быть несколько ведущих. Для такой связи заводят третью таблицу из пар «человек, услуга».
• Один к одному: встречается реже, например профиль к учётной записи.

Как найти сущности своего проекта

Сущность это вид «вещей», о которых сайту надо помнить, у которого много экземпляров. Каждая сущность становится таблицей. Найти их в брифе можно за четыре шага.

1. Выпишите существительные из своего брифа: услуги, люди, подтверждения, заявки, разделы.
2. Оставьте те, у которых будет много экземпляров и которые живут своей жизнью. «Заявка» подходит: их много, и у каждой своя дата. «Тон сайта» нет: он один.
3. Каждой сущности дайте ключ и поля. Поля возьмите из брифа: у услуги это название, описание и цена.
4. Нарисуйте связи: «заявка ссылается на услугу».

Отдельный разговор о заявках. Заявка из формы почти всегда отдельная сущность, а не поле какой-то другой. Заявок у одной услуги много, у каждой свои дата и контакты, а ещё это персональные данные посетителя: по имени и телефону можно узнать живого человека. К таким данным закон предъявляет требования, и хранить их надо отдельно и по правилам. Про это будет урок 7 этой части, а пока достаточно пометить такие поля на схеме.

Когда базы не нужно

Честный вывод урока: база вашему проекту может не понадобиться. Если на сайте пять услуг, которые меняются дважды в год, а заявки уходят на почту через сервис-посредник, то услуги можно хранить прямо в файле (мы увидим как в части 8, на Markdown), а заявки никто не хранит у вас. Сайт, который вы строите в этом курсе, устроен именно так: у него нет базы, и это сознательное решение.

Базу стоит заводить, когда есть хотя бы одно из трёх: данные пишут посетители; данными одновременно занимаются несколько человек; данных так много, что их нужно искать и сочетать (фильтры, сортировки, отчёты).

Практика

Вы в эпохе 2010 года. Сайты на CMS уже умеют хранить статьи и комментарии в базе, а владельцы малого бизнеса всё ещё ведут заявки в Excel и вручную переносят их на сайт. Чтобы не вести двойную работу, начните со схемы данных вашего проекта.

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

Что было не так с Excel вместо базы

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