Главное Свежее Вакансии   Проекты
Комментируемое:

Список ссылок временно недоступен
😼
Выбор
редакции
998 0 В избр. Сохранено
Авторизуйтесь
Вход с паролем

SQL Driven. Учетная система с ориентацией на SQL

В статье описан подход, когда во главу угла ставится 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 для таблицы вывода страниц

Так выглядит таблица в компактном режиме

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

Процедуры делятся на системные (обслуживают компоненты и внутренние потребности системы) и пользовательские (задают вывод данных).

Редактирование процедур происходит через интерфейс панели управления, т.е. нет необходимости искать каждый раз хранимую процедуру в 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/

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Первые Новые Популярные
Комментариев еще не оставлено
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.