редакции
Руслан Раянов
SQL Driven. Учетная система с ориентацией на SQL
Что есть полный стек разработки?
Самописные системы разрабатываются на базе полного стека разработки с N слоями:
- проектируется база данных
- создается слой доступа к данным
- создается слой бизнес-логики
- разрабатывается API или слой контроллеров
- делается верстка
- к ней подключается динамика за счет front end программирования.
Это довольно трудоемко, сложно. Но этому есть причина. Коробочные решения не дают гибкости, а для дальнейшего развития системы очень важно иметь возможность легко развивать систему без серьезных ограничений.
Когда то давно мы создали модуль метрик, который генерировал некие отчеты в виде вложенных показателей. Каждый отчет — это данные в таблицах + некая хранимая процедура для извлечения данных.
Движок модуля подхватывал эти данные и хранимку и выводил все что нужно пользователю.
Это привело нас к идее, а почему бы и другие все модули не попробовать сделать по подобному принципу — формы, таблицы, графики, дашборды и прочее.
Что дает в итоге такой подход:
во-первых, можно менять бизнес-логику на лету (просто поменяв хранимую процедуру). В случае обычного N-слойного приложения необходима перекомпиляция и обновление программы.
во-вторых, что следует из первого — это скорость внесения изменений. Очень важно иметь возможность быстро вносить изменения, а не ждать разработчиков по 2 недели, когда они внедрят изменения в систему.
в-третьих, основная сложность ложится на 1 слой и локация ошибки с высокой степенью вероятности находится только в 1 слое — SQL процедурах. Это упрощает поиск ошибок и минимизирует количество сбоев на front end.
Как это выглядит изнутри
Возьмем к примеру вывод таблицы.
На входе — это сниппет
Ваш JS движок обрабатывает подобные компоненты и запрашивает у базы описание по компонентам и данные для них (все через знанимые процедуры).
Полученные данные JS движок выводит в виде таблицы. Данные удовлетворяют неким правилам/стандартам. Например для таблиц у нас правила примерно выглядят так:
процедура GetItems выдает в SELECT 1 данные таблицы, в SELECT 2 — данные о пагинации, в SELECT 3 — настройки вывода таблицы.
К примеру если в select 3 передать select 1 compact — то таблица будет выведена в компактном режиме.
Если необходимо реализовать какие-то действия с данными таблицы, то это также вызов некой хранимой процедуры с заданными параметрами и заданным выводом.
Процедуры делятся на системные (обслуживают компоненты и внутренние потребности системы) и пользовательские (задают вывод данных).
Редактирование процедур происходит через интерфейс панели управления, т.е. нет необходимости искать каждый раз хранимую процедуру в SQL Server Management Studio.
Плюсы и минусы подхода
Какие дополнительные плюсы дает подобный подход?
1. Быстродействие. Вы рабочаете с чистым SQL без лишних прослоек в виде ORM. Это дает хорошее быстродействие и оно ограничивается по сути быстродействием вашего написанного SQL запроса.
2. Созданный функционал — это по сути только SQL и данные в таблицах (что также можно представить в виде SQL скрипта). Вы можете легко переносить между разными системами SQL для отдельных компонентов. Это возможность наращивать кодовую базу и адаптировать ее в других подобных приложениях.
3. Не нужна компиляция. Поменяли процедуру — получили сразу в системе другой результат. По сути разработка идет в realtime, параллельно с использованием.
4. Локализация ошибок — большинство ошибок лежат в вашем SQL, а не разбросаны по всему стеку. Есть проблема? Проверяем работы процедуры в SQL Management Studio и анализируем вход и выход.
5. Поняв общий подход, систему можно развивать, добавляя новые блоки и модули без необходимости менять исходный код программы.
6. Уменьшение требуемых компетенций для поддержки системы. В нашем случае мы сводим все к 2 компетенциям — знание SQL и Bootstrap.
7. Уменьшение количества велосипедов. Программисты не могут больше делать в системе 3 вида по разному сделанных таблиц. Все унифицируется и разработка идет быстрее.
Конечно не все так просто и есть свои сложности, например, некоторые функции не так просто реализовать в SQL (вычисление хеша для кириллицы) или передача вызова из хранимой процедуры в код веб-приложения. Где-то приходится идти на компромиссы (например есть ограничения верстки отдельных элементов).
Однако в целом такой подход позволяет решать ключевые задачи — быстро создавать необходимый функционал и иметь гибкие возможности по дальнейшему развитию.
P.S. В предыдущей статье мы рассказали историю создания нашей системы Falcon Space, основанной на данном подходе.
Конструктор учетных систем и личных кабинетов — https://falcon.web-automation.ru/