Почему мы не используем PHP и Java в бизнес-логике – надёжность и простота SQL

Спор между приверженцами SQL и традиционных языков программирования (PHP, Java, C#) ведётся годами. Одни говорят: «Всю логику надо писать в коде, а база данных должна быть только хранилищем». Другие (включая нас) утверждают, что бизнес-логику безопаснее, быстрее и дешевле реализовывать на SQL, прямо внутри базы данных.

Falcon Space построен на этом принципе: ядро платформы написано на C#, а вся бизнес-логика вашего приложения — это хранимые процедуры MS SQL. Почему? Потому что за 10 лет разработки мы пришли к выводу: SQL надёжнее, быстрее и проще для поддержки, чем любой другой язык.

Расскажу, почему мы сделали такой выбор и какие преимущества это даёт вам как бизнесу.

Надёжность: меньше ошибок, легче отладка

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

В SQL вся логика сосредоточена в хранимых процедурах. Ошибка (если она есть) почти всегда находится в одной процедуре. Вы видите сообщение об ошибке, номер строки, понимаете, что пошло не так. Исправили — и готово.

Кроме того, SQL — это декларативный язык: вы описываете, что нужно сделать (SELECT, UPDATE), а не как. Меньше кода — меньше ошибок. В процедуре из 20 строк сложно ошибиться, в 2000 строк на Java — легко.

Статистика по нашим проектам: количество критических ошибок в бизнес-логике на Falcon Space в 5-10 раз меньше, чем в предыдущих проектах, написанных на C#. Мы связываем это именно с простотой SQL.

Производительность: быстрее, чем любой серверный код

Когда вы делаете расчёт на PHP или Java, происходит следующее: данные из БД передаются на сервер приложений, там выполняются вычисления (циклы, условия), результат передаётся обратно. Это много сетевых вызовов и пересылок.

В SQL расчёт происходит прямо внутри базы данных, рядом с данными. Нет лишней пересылки. Для больших объёмов данных разница колоссальная. Например, расчёт бонусов для 10 000 клиентов на PHP может занять 10-15 секунд, а на SQL — 0,5 секунды. Потому что SQL оптимизирует выполнение, использует индексы, не гоняет данные туда-сюда.

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

Конечно, если у вас всего 100 клиентов, разницы не заметно. Но когда бизнес растёт и база достигает миллионов строк, SQL становится незаменим.

Простота поддержки: кто знает SQL, справится

PHP-разработчиков много, но хороших — мало. Java-разработчиков ещё меньше, и они дорогие. SQL-специалистов тоже много, но главное — SQL изучается быстрее. Менеджер по продажам, который знает Excel, может освоить SQL за 2 недели и начать писать простые отчёты. Для PHP понадобятся месяцы.

Это значит, что вы не привязаны к команде программистов. Если ваш разработчик на PHP уволится, найти нового сложно и дорого. Если уволится SQL-специалист, любой другой справится с вашими процедурами (если они написаны аккуратно).

Мы сами используем Falcon Space для внутренних нужд, и наши менеджеры пишут SQL-запросы для отчётов. Они не программисты, но знают SELECT, WHERE, JOIN — и этого достаточно.

Безопасность: защита от SQL-инъекций

Парадокс: многие считают, что SQL-код опасен (SQL-инъекции). Но на самом деле опасен не SQL, а динамическое построение запросов из строк. Если вы используете хранимые процедуры с параметрами, SQL-инъекции невозможны, потому что параметры передаются строго типизированно, и их нельзя интерпретировать как код.

В PHP и Java разработчики часто пишут код, который уязвим (например, склеивают строки). Хорошая практика — использование ORM, но она не спасает от всех векторов атак.

В Falcon Space мы настаиваем, чтобы все процедуры были параметризованными. Это базовое правило, которое исключает целый класс уязвимостей.

Когда SQL не подходит (честно)

SQL хорош для данных и операций с ними, но не для всего. Вот примеры, где лучше использовать классический язык:

• Сложные математические модели (машинное обучение, оптимизация).
• Интеграции с протоколами, не поддерживаемыми SQL (WebSockets, низкоуровневые сетевые вызовы).
• Алгоритмы с большим объёмом временных данных (курсоры, рекурсии на больших данных могут быть медленны).

Но для 95% бизнес-задач (расчёты скидок, агрегация отчётов, проверка статусов, формирование документов) SQL идеален.

Пример: расчёт комиссии и выплат на маркетплейсе

В проекте OPTUBER (площадка для закупок) было требование: при нажатии кнопки «Выбрать победителя» система должна рассчитать комиссию площадки (5%), зарезервировать деньги, отправить уведомление поставщику и создать запись в бухгалтерии. Всё это — одна SQL-процедура, которая:

• Обновляет статус заявки.
• Вставляет запись в таблицу выплат.
• Вызывает внешнее действие для отправки уведомления.
• Возвращает результат.

Если бы мы писали это на Java, пришлось бы создавать несколько методов, транзакцию, вызовы API. Кода было бы в 10 раз больше. Риск ошибки — выше.

На SQL процедура заняла 30 строк. Работает без ошибок уже год, изменения вносились трижды (меняли процент комиссии) — это заняло 5 минут.

Вывод: SQL — не «второсортный» язык

SQL — это мощный, полноценный язык для работы с данными. Он не хуже PHP или Java, он просто другой. И для бизнес-логики, которая вращается вокруг данных, он подходит лучше. Дешевле, быстрее, надёжнее.

Мы сделали Falcon Space именно таким, потому что верим в SQL. И наши клиенты, сэкономившие миллионы на поддержке, подтверждают наш выбор.

Насколько полезной была статья?