Когда пользователь открывает Corgish, создаёт новый квиз, добавляет вопросы, приглашает участников и просматривает результаты, он взаимодействует с понятным интерфейсом. Однако за каждым действием скрывается работа с большим количеством связанных данных.
Сервису необходимо хранить информацию о пользователях, ролях, квизах, вопросах, вариантах ответа, попытках прохождения, участниках, баллах и результатах. При этом данные должны сохраняться быстро, не дублироваться, не теряться и оставаться доступными при росте нагрузки.
За надёжность этой системы отвечает не только backend-разработчик. Ещё до появления кнопок и экранов необходимо определить, как будет устроено само хранилище данных. Эту задачу решает архитектор баз данных.
Мы поговорили с Александром Шульгиным о его профессиональном пути, работе с PostgreSQL и MySQL, проектировании структуры данных и инструментах вроде DBeaver, pgAdmin, Draw.io и ERwin. Также обсудили, зачем архитектору нужны SQL, Git, системное мышление и понимание DevOps/SRE.
Интервью будет полезно начинающим разработчикам, аналитикам, студентам и всем, кому интересно, как изнутри устроены цифровые продукты — в том числе сервисы онлайн-викторин, подобные Corgish.
Расскажите о своём профессиональном пути и о том, как вы пришли в профессию архитектора баз данных
Мой путь в IT начался с практической необходимости ещё на первом курсе по направлению «Разработка и сопровождение программных продуктов».
Первым серьёзным вызовом стала курсовая работа, которая по сути была полноценным проектом. В то время не было такого доступа к готовым решениям и инструментам искусственного интеллекта, как сейчас. Поэтому всё приходилось изучать самостоятельно: читать литературу, искать ответы на форумах и методом проб и ошибок проходить все этапы разработки.
Этот опыт «выживания» и глубокая личная вовлечённость в создание продукта с нуля заложили основу моего понимания разработки.
Осознанный интерес к данным появился на втором курсе. Мне очень нравился предмет, посвящённый работе с системами управления базами данных. Меня привлекали его скрупулёзность, целостность и логичность, хотя многим одногруппникам он казался монотонным.
Позже, работая в командах над программным обеспечением и сайтами, я наблюдал, насколько сильно качество данных и продуманность их структуры влияют на всё приложение.
Окончательно всё сложилось, когда я начал разрабатывать собственный проект — сервис бронирования проживания для вузов России. В этом проекте мне пришлось одновременно выполнять роли разработчика, аналитика и архитектора.
Я погрузился в проектирование сложной, но эффективной схемы базы данных, где каждое отношение и каждый индекс должны были находиться на своём месте, обеспечивая скорость работы и целостность информации.
Этот опыт и стал точкой перехода от общей разработки к специализации на архитектуре данных.
Как это связано с Corgish
В сервисе онлайн-викторин ситуация похожая. На раннем этапе один человек или небольшая команда могут одновременно проектировать интерфейс, разрабатывать backend и определять структуру данных.
Но по мере развития продукта количество сущностей растёт. Помимо пользователей и квизов появляются группы, роли, папки, лекции, расписание, разные редакторы, результаты прохождений и аналитика.
Если структура данных изначально не рассчитана на развитие, каждое новое обновление становится сложнее внедрять. Поэтому архитектурные решения, принятые на старте, напрямую влияют на скорость дальнейшего развития Corgish.
Как вы обычно объясняете, кто такой архитектор баз данных, человеку без технического образования?
Архитектора баз данных проще всего представить как главного проектировщика хранилища данных компании.
Можно провести аналогию с библиотекой. Backend-разработчики строят само здание и настраивают процессы выдачи книг. Архитектор при этом думает о фундаментальных вещах:
как расположить стеллажи и каталоги, чтобы любую книгу можно было найти за секунды;
как организовать работу, чтобы несколько сотрудников одновременно добавляли новые книги и не создавали путаницу;
как защитить ценную информацию от посторонних;
как подготовить систему к ситуации, когда количество книг вырастет в десятки раз.
Ключевая задача архитектора — спроектировать систему хранения данных так, чтобы она работала быстро, без сбоев и оставалась готовой к росту.
По сути, архитектор баз данных создаёт структурированный и надёжный фундамент, на котором строятся цифровые сервисы.
Что именно хранится в базе данных Corgish
На примере Corgish можно представить, насколько много объектов связано внутри одного сервиса:
пользователь создаёт аккаунт;
пользователь получает роль участника или организатора;
организатор создаёт квиз;
квиз содержит вопросы;
вопросы содержат варианты ответа;
квиз запускается в определённом режиме;
к игре подключаются участники;
каждый участник даёт ответы;
система рассчитывает баллы;
результаты сохраняются для аналитики;
организатор просматривает статистику прохождения.
Все эти сущности должны быть правильно связаны между собой. Если удалить квиз, система должна понимать, что произойдёт с вопросами, играми и результатами. Если пользователь изменил имя, обновление не должно повредить историю его прохождений.
Архитектор базы данных заранее определяет правила, которые позволяют системе сохранять целостность.
В каких задачах и ситуациях роль архитектора баз данных становится особенно важной?
Роль архитектора критически важна на старте нового продукта или при его кардинальном изменении.
Например, в моём проекте сервиса бронирования неправильно выбранная структура данных могла привести к невозможности масштабирования, снижению скорости при росте количества пользователей и проблемам с целостностью информации — вплоть до двойного бронирования одного объекта.
Архитектор также незаменим при оптимизации унаследованных систем, которые начинают тормозить и ломаться под нагрузкой.
Часто проблема находится не в программном коде, а в фундаменте — в том, как данные организованы, связаны и запрашиваются.
Почему архитектура особенно важна при развитии Corgish
Предположим, что изначально сервис позволял создавать только простые квизы с одним правильным ответом.
Позже в продукте появляются:
сопоставление;
верный порядок;
открытые вопросы;
оценочные квизы;
разные варианты результатов;
лекции;
группы пользователей;
приватный доступ;
расписание;
расширенная аналитика.
Каждая новая функция меняет требования к данным.
Например, в обычном квизе есть правильный ответ. В оценочном квизе правильного ответа может не быть, а результат зависит от суммы баллов или диапазона значений.
Если база данных была жёстко спроектирована только под один формат, добавление нового редактора потребует сложной переработки. Хорошая архитектура должна учитывать развитие продукта, но при этом не быть чрезмерно усложнённой заранее.
Чем работа архитектора баз данных отличается от работы backend-разработчика или аналитика данных?
Это три разных специалиста, которые работают с данными на разных этапах.
Backend-разработчик создаёт функции сервиса. Например, он реализует кнопку «Сохранить заказ» и логику, которая отправляет информацию в базу данных.
Аналитик данных, наоборот, получает информацию из хранилища, анализирует количество заказов, определяет популярные товары и строит отчёты.
Архитектор баз данных проектирует само хранилище. Он определяет, как база будет устроена внутри и как необходимо разложить данные, чтобы операции сохранения и анализа выполнялись быстро, информация не терялась, а система выдерживала рост нагрузки.
Иными словами, архитектор создаёт фундамент, на котором уже работают разработчики и аналитики.
Разница ролей на примере Corgish
В сервисе онлайн-викторин распределение может выглядеть следующим образом.
Backend-разработчик реализует действие кнопки «Сохранить квиз». Он проверяет полученные данные и записывает название, описание, вопросы и варианты ответа.
Аналитик изучает, сколько квизов создают пользователи, какие тематики популярны, сколько человек проходит тесты и на каких вопросах участники чаще ошибаются.
Архитектор базы данных определяет:
в каких таблицах хранятся квизы;
как вопросы связаны с квизом;
как сохраняются варианты ответа;
как разделяются черновики и опубликованные материалы;
как хранить историю прохождений;
как не потерять результаты при изменении квиза;
какие индексы нужны для быстрого поиска.
Все три роли связаны, но решают разные задачи.
С какими типами баз данных вы работаете чаще всего и почему?
Мой основной опыт сосредоточен на реляционных базах данных, в частности PostgreSQL и MySQL.
Они остаются рабочими инструментами для большинства бизнес-приложений, особенно там, где критически важны:
целостность данных;
транзакции;
сложные связи между сущностями;
предсказуемость операций;
надёжность хранения.
С PostgreSQL и MySQL я работал как в командах, так и в собственных проектах. Этот стек был выбран ещё во время студенчества.
При этом я стараюсь не останавливаться на достигнутом. Когда понимаю, что достаточно глубоко освоил текущий инструмент, начинаю изучать другие подходы.
Даже если в основной практике часто применяются проверенные решения, знание других технологий расширяет кругозор и помогает выбирать оптимальный инструмент для конкретной задачи.
Почему реляционная модель подходит сервису квизов
У сервиса онлайн-викторин много структурированных связей.
Один пользователь может создать несколько квизов. Один квиз содержит несколько вопросов. Один вопрос может содержать несколько вариантов ответа. В одной игровой сессии участвует несколько пользователей, каждый из которых отвечает на несколько вопросов.
Такие отношения удобно описывать с помощью реляционной модели.
Например:
Пользователь → Квиз → Вопрос → Вариант ответа
Отдельно могут храниться:
Игровая сессия → Участник → Ответ → Результат
Реляционная база данных позволяет зафиксировать эти связи и контролировать их целостность.
Какие базовые знания необходимы человеку, который только задумывается о начале обучения этой профессии?
Для старта я бы посоветовал сформировать чёткий фундамент.
Необходимо понять основы реляционной модели:
таблицы;
строки;
столбцы;
первичные ключи;
внешние ключи;
связи между сущностями.
Также важно освоить базовый SQL для выборки и соединения данных и научиться мыслить абстрактно, чтобы видеть объекты реального мира и отношения между ними.
Не менее важны любопытство и привычка внимательно читать документацию. Архитектор должен осознанно понимать, почему выбирает одну структуру хранения данных вместо другой.
Наблюдая за студентами, я часто замечаю, как им мешает излишняя торопливость и желание сразу переходить к действиям, не обдумывая шаги.
В нашей работе это недопустимо. Ошибки, допущенные во время проектирования, болезненно проявляются на финальных этапах и могут заставить переделывать проект практически с нуля.
Поэтому я бы добавил ещё два важных качества: скрупулёзность и методичность.
Мне тоже не раз приходилось начинать сначала. Через ошибки я пришёл к пониманию, что аккуратность и продуманность на старте экономят огромное количество времени и сил в дальнейшем.
Учебный проект: база данных для сервиса квизов
Начинающему специалисту необязательно сразу проектировать банковскую систему или крупный маркетплейс.
В качестве первого проекта можно разработать упрощённую модель сервиса онлайн-викторин.
Попробуйте определить:
какие данные нужны для регистрации пользователя;
как хранить квизы;
как связать вопросы и варианты ответа;
как отметить правильный вариант;
как сохранить попытку прохождения;
как рассчитать результат;
как показать историю тестов пользователя.
Такой учебный проект помогает познакомиться с реальными связями и ограничениями, но остаётся понятным начинающему специалисту.
Насколько важно знание SQL на старте и на каком уровне его достаточно для начинающего?
SQL — это не просто язык. Это способ мышления о данных.
На старте он является одним из самых важных навыков.
Для начала достаточно уверенно владеть основными операциями:
выборкой данных;
добавлением записей;
обновлением;
удалением;
соединением таблиц;
агрегацией;
простыми подзапросами.
Необязательно сразу переходить к оконным функциям или сложной оптимизации.
Важнее не бояться брать небольшие проекты, чтобы получать практический опыт уже во время обучения.
Например, с помощью SQL можно ответить на вопросы, важные для сервиса квизов:
сколько тестов создал пользователь;
сколько участников прошло определённый квиз;
какой вопрос оказался самым сложным;
какой участник набрал больше всего баллов;
сколько попыток было совершено за неделю;
какие квизы чаще запускают преподаватели.
Такие задачи помогают увидеть, что SQL используется не изолированно, а для решения конкретных продуктовых и аналитических задач.
Какие математические или логические навыки действительно нужны архитектору баз данных?
Глубокая высшая математика в повседневной работе требуется нечасто.
Самое важное — развитое логическое и структурное мышление.
Один мой школьный учитель говорил, что ключ к успеху в сложных задачах заключается не в запоминании формул, а в умении анализировать каждый шаг, подвергать решения сомнению и заранее планировать последовательность действий.
На практике это означает способность разбивать сложную бизнес-задачу на простые связанные сущности.
Например, систему бронирования столика необходимо представить как набор объектов:
пользователь;
ресторан;
столик;
дата;
временной интервал;
бронирование;
статус.
Для сервиса онлайн-викторин логика будет похожей:
автор;
квиз;
вопрос;
ответ;
участник;
игровая сессия;
результат.
Также важно понимать основы теории множеств, поскольку работа с таблицами в базе данных во многом представляет собой работу с наборами строк.
Какие ошибки чаще всего совершают новички при изучении баз данных и архитектуры?
Одна из распространённых ошибок — пренебрежение теорией.
Новички сразу начинают писать код, не разобравшись в нормальных формах. В результате появляются избыточные данные и аномалии.
Также часто встречаются следующие проблемы:
непонимание разницы между первичными и уникальными ключами;
неправильный выбор типов данных;
поверхностный анализ задачи;
преждевременная оптимизация;
ненужное дробление таблиц;
добавление индексов без понимания нагрузки;
игнорирование целостности данных;
попытка контролировать связи только на уровне приложения;
слепое следование технологическим трендам.
Например, разработчик может выбрать популярный тип базы данных только потому, что о нём много говорят, хотя задача лучше решается с помощью обычной реляционной модели.
К чему ошибки могут привести в сервисе онлайн-викторин
Непродуманная структура данных способна вызвать реальные проблемы:
один ответ участника сохраняется несколько раз;
результаты квиза рассчитываются неправильно;
после редактирования вопроса исчезает история старой игры;
пользователь получает доступ к приватному тесту;
удаление аккаунта повреждает статистику;
аналитика показывает неверное количество участников;
поиск квизов работает слишком медленно;
при одновременном подключении большого количества участников система перестаёт справляться с нагрузкой.
Поэтому архитектура базы данных влияет не только на внутреннюю разработку, но и на пользовательский опыт.
Какие инструменты или технологии вы бы рекомендовали изучать в первую очередь?
Основной набор для старта достаточно стандартный.
В качестве базы данных можно выбрать одну из популярных реляционных СУБД:
PostgreSQL;
MySQL.
Для визуального проектирования структуры пригодятся:
ERwin.
Они позволяют сначала представить схему в виде диаграммы, а уже затем переходить к написанию кода.
Для выполнения запросов и администрирования базы данных можно использовать:
DBeaver;
pgAdmin.
Обязательно стоит освоить Git. Под контроль версий помещаются не только файлы приложения, но и скрипты, изменяющие структуру базы данных.
Полезно также изучить основы командной строки для выполнения базовых операций с сервером и СУБД.
Как может выглядеть схема Corgish в Draw.io
Даже упрощённая схема сервиса онлайн-викторин может включать следующие блоки:
Users;
Quizzes;
Questions;
AnswerOptions;
GameSessions;
Participants;
ParticipantAnswers;
Results.
На диаграмме можно показать, как пользователь связан с созданным квизом, как вопросы относятся к определённому тесту и как ответы участника сохраняются внутри игровой сессии.
Такое визуальное проектирование помогает заметить ошибки ещё до создания таблиц.
Как обычно выглядит рабочий процесс архитектора баз данных на проекте?
Работа начинается с анализа бизнес-требований.
Необходимо определить, какие данные нужны продукту и как они связаны между собой.
Следующий этап — проектирование концептуальной и логической модели данных. Она обсуждается с разработчиками и другими участниками команды.
После утверждения модель переносится в физическую реализацию:
определяются типы данных;
выбираются индексы;
продумывается стратегия хранения;
создаются скрипты развёртывания;
настраиваются ограничения.
Финальный этап включает создание базы данных, миграцию существующей информации и сопровождение команды во время запуска системы.
Как этот процесс может выглядеть при добавлении функции в Corgish
Предположим, команда хочет добавить оценочные квизы.
Сначала необходимо описать бизнес-логику:
какие типы вопросов будут доступны;
как начисляются баллы;
сколько результатов может создать автор;
как определяются диапазоны результатов;
что увидит участник после прохождения.
После этого архитектор определяет:
какие новые сущности потребуются;
можно ли расширить существующую модель;
где хранить настройки шкалы;
как хранить диапазоны результатов;
как обеспечить совместимость со старыми квизами;
что произойдёт с уже сохранёнными прохождениями после редактирования.
Только после этого backend-разработчик начинает реализовывать новую функцию.
С какими специалистами архитектор баз данных взаимодействует чаще всего?
Наиболее тесное сотрудничество происходит с backend-разработчиками.
Взаимодействие включает:
совместное ревью запросов;
обсуждение интерфейсов для работы с данными;
планирование изменений схемы базы;
оптимизацию производительности.
В начале проекта важными партнёрами становятся бизнес-аналитики и продакт-менеджеры. Вместе с ними архитектор проводит интервью и рабочие сессии, чтобы собрать и уточнить требования.
Если продукт интегрируется в инфраструктуру образовательных учреждений, необходимо взаимодействовать с их IT-отделами.
Для обеспечения надёжности системы архитектор также сотрудничает с DevOps- и SRE-инженерами. Вместе они настраивают:
репликацию;
резервное копирование;
мониторинг;
восстановление после сбоев;
отказоустойчивость.
Для Corgish такое взаимодействие особенно важно во время запуска онлайн-викторин. Если к игре одновременно подключается большое количество участников, система должна стабильно принимать ответы и сохранять результаты без задержек.
Какие софт-навыки оказываются важными для успешной работы?
В первую очередь важна коммуникация.
Архитектору необходимо уметь объяснять бизнесу технические ограничения и одновременно понимать задачи продукта.
Также требуется системное мышление — способность видеть не отдельную таблицу или функцию, а всю картину проекта.
Важно уметь работать с нечёткими требованиями, предлагать гибкие решения и проявлять проактивность, отслеживая производительность системы по мере роста данных.
Мне сильно помог опыт самостоятельного поиска ответов. Он развил любознательность и привычку мысленно визуализировать каждый процесс. В шутку это можно назвать здоровой дотошностью.
Архитектору недостаточно просто сказать, что функция «не поместится в текущую структуру». Необходимо объяснить продуктовой команде, какие существуют варианты, сколько времени займут изменения и какие риски есть у каждого решения.
Сколько времени нужно, чтобы освоить базовый уровень и начать двигаться в профессии?
Если у человека уже есть технический опыт, на формирование фундаментального понимания баз данных и уверенное освоение SQL обычно уходит от трёх до шести месяцев активного обучения.
Чтобы вырасти до уровня начинающего специалиста, способного работать в команде под руководством более опытного коллеги, может потребоваться около года.
Главный секрет заключается не в простом изучении теории, а в её обязательном применении на практических задачах.
Многие слышали о базах данных, но не все понимают, как они устроены внутри. Здесь появляется возможность разобраться в самом механизме работы цифрового продукта.
По моим наблюдениям за студентами, при грамотной практике и наглядном разборе конкретных кейсов они осваивают базы данных быстрее, чем многие другие технологии программирования. Кроме того, практические задачи вызывают больше вовлечения и интереса.
Как Corgish можно использовать при изучении баз данных
После изучения темы преподаватель может создать в Corgish проверочный квиз по SQL и архитектуре данных.
В него можно добавить вопросы:
чем первичный ключ отличается от внешнего;
зачем нужна нормализация;
что делает индекс;
чем PostgreSQL отличается от MySQL;
как связаны таблицы пользователей и квизов;
почему нельзя хранить все данные в одной таблице;
что произойдёт при нарушении ссылочной целостности.
Так студенты сначала проектируют модель данных, а затем проходят онлайн-викторину и проверяют понимание основных терминов.
Что бы вы посоветовали человеку, который только рассматривает профессию архитектора баз данных и сомневается, стоит ли начинать?
Мой путь начался с вынужденной задачи, но продолжился благодаря искреннему интересу к порядку и структуре.
Возьмите любой собственный проект, даже небольшой, и попробуйте спроектировать для него базу данных.
Например, можно создать модель:
интернет-магазина;
библиотеки;
системы бронирования;
образовательной платформы;
сервиса онлайн-викторин.
Если вас затянет процесс превращения хаоса в чёткую структуру и появится удовольствие от того, что все элементы встают на свои места, возможно, эта профессия вам подходит.
Если интереса не возникнет, вы хотя бы исключите один вариант и станете ближе к пониманию собственного направления.
Не получится узнать, не попробовав.
Почему архитектура данных важна для Corgish
Пользователь оценивает цифровой продукт по интерфейсу: насколько легко создать квиз, добавить вопрос, запустить онлайн-викторину и посмотреть результаты.
Но удобство интерфейса невозможно без устойчивого внутреннего устройства.
Архитектура данных влияет на то:
как быстро открывается редактор квизов;
сохраняются ли изменения;
не теряются ли ответы участников;
правильно ли рассчитываются результаты;
насколько быстро строится аналитика;
можно ли добавлять новые форматы тестов;
выдерживает ли сервис рост количества пользователей;
защищены ли приватные данные.
Поэтому разработка Corgish — это не только дизайн экранов и написание программного кода. Это также постоянная работа со структурой, связями, производительностью и целостностью данных.
Именно специалисты по архитектуре баз данных помогают создать фундамент, на котором сервис может развиваться, добавлять новые редакторы, расширять аналитику и поддерживать всё больше пользователей.
Если у вас остались вопросы к Александру Шульгину, вы можете задать их лично:
https://t.me/alexshulgin7
А проверить знания по SQL, базам данных и архитектуре цифровых продуктов можно с помощью собственного квиза в редакторе Corgish.