SQL · BIG FISH

Проектирование баз данных и SQL-разработка

Проектируем структуру данных, запросы и отчёты для цифровых продуктов. Работаем с целостностью, конкурентными изменениями и измеримой производительностью.

Попробовать пример ↗Документация ↓

BIG FISH / SQL

01Параметры отчёта

02План доступа

03Отбор и группировка

04Проверяемый результат

Дизайн × технология × ваш процесс

ВОЗМОЖНОСТИ ПРОДУКТА

Технология становится
рабочим инструментом.

Модель продукта

Связанные сущности, ключи и правила целостности данных.

Управленческий отчёт

Отбор и агрегация с проверяемым смыслом каждого показателя.

Измеримая оптимизация

Запросы и индексы под реальные операции и объём данных.

ЖИВОЙ ПРИМЕР

Проверьте сценарий.
Посмотрите результат.

Отчёт по оплаченным заказам сети филиалов. Выберите филиал и способ поиска: итог одинаковый, но число просмотренных записей в учебной модели различается.

Учебный пример с условными данными. Действия остаются в браузере. Это модель сценария, а не подключённая CMS, сервер или база данных.

SQL

ФилиалСпособ доступа

120 условных заказов. Учитываются только оплаченные.

SQLРезультат сценария

Учебный пример готов к запуску.

АРХИТЕКТУРА СЦЕНАРИЯ

У каждого шага
своя ответственность.

Параметры отчёта

План доступа

Отбор и группировка

Проверяемый результат

Что проверяем перед запуском
Слой	Результат
Интерфейс	Понятны ввод, ограничения, загрузка и ошибки. Доступно управление клавиатурой.
Данные	У значений есть владелец, формат и правила актуальности.
Выпуск	Проверены ключевые сценарии, резервирование и восстановление.

Иллюстрация дизайна цифрового продукта на SQL — Иллюстрация цифрового сервиса

BIG FISH · SQL

Данные, которые можно прочитать.

Работа с базами данных SQL отражается в интерфейсе отчётов: какие показатели сравнивать, по какому периоду и с какой детализацией. Проектируем таблицы, фильтры и диаграммы так, чтобы итог можно было проверить по исходным записям.

Для аналитических панелей и CRM продумываем единицы измерения, отсутствующие значения и время обновления. Пустая выборка отличается от нуля, а изменение фильтра не должно незаметно менять смысл показателя.

ПРАКТИЧЕСКОЕ РУКОВОДСТВО

Как устроен продукт
на SQL.

Архитектура, ограничения и проверяемые сценарии. Конкретную конфигурацию согласуем по требованиям проекта.

SQL / 01

Предметная модель

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

Проверка на проекте
История заказа переживает обновление прайса.

SQL / 02

Целостность данных

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

Проверка на проекте
Дублирующий ключ отклоняется базой.

SQL / 03

Соединения и агрегация

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

Проверка на проекте
Соединение не удваивает сумму заказа.

SELECT branch_id, SUM(amount_minor) AS paid_total
FROM orders
WHERE status = :status AND branch_id = :branch
GROUP BY branch_id;

SQL / 04

Индексы и планы

Индекс проектируем под реальные условия отбора, соединения и сортировки. Порядок полей в составном индексе имеет значение. План выполнения помогает понять выбранный способ доступа, но оценивается вместе с объёмом и распределением данных. В демонстрации показываем число просмотренных строк в JavaScript-модели, а не замер скорости настоящей СУБД.

Проверка на проекте
Оба способа доступа дают одинаковый итог.

SQL / 05

Транзакции и конкуренция

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

Проверка на проекте
Конкурирующие изменения не теряют данные.

SQL / 06

Миграции схемы

Добавление обязательного поля к большой таблице требует плана заполнения существующих данных. Изменения выпускаем с учётом одновременной работы старого и нового кода. Проверяем длительность блокировок на сопоставимом объёме. Обратная миграция не всегда восстанавливает удалённые значения, поэтому опасные преобразования нуждаются в отдельной резервной копии.

Проверка на проекте
Большая таблица мигрирует по согласованному плану.

SQL / 07

Доступ и запросы

Пользователь приложения получает только необходимые права базы. Параметризуем значения, ограничиваем динамические имена таблиц и полей. Изоляцию данных компаний проверяем во всех запросах, включая выгрузки. Нельзя считать скрытый фильтр интерфейса защитой от доступа к чужим записям. Журналы запросов не должны бесконтрольно раскрывать чувствительные данные.

Проверка на проекте
Выгрузка не содержит чужую организацию.

SQL / 08

Восстановление и наблюдение

Согласуем допустимую потерю данных и время восстановления. Резервная копия полезна, только если её можно восстановить и проверить. Наблюдаем медленные запросы, рост таблиц и ошибки блокировок. Репликация может помогать доступности и чтению, но не заменяет резервирование: ошибочное удаление способно распространиться и на реплику.

Проверка на проекте
Время восстановления проверено на копии.

FAQ

Вопросы перед стартом

Это готовое решение?

Нет. Пример показывает проектируемый сценарий для SQL. Рабочую систему разрабатываем под ваши требования, данные и интеграции.

Можно сохранить существующие системы?

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

Что получим при передаче проекта?

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

Спроектируем ваш продукт

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