o7412369815963
Это не вспомогательный сервер!
Это расширение функционала.
Пример.
Я пока не останавливаюсь на месте хранения бизнес-логики. Об этом ниже.
Если у вас система маленькая, вам не нужна вся мощь СУБД и параллельное масштабирование вы не используете, то вы обходитесь одним сервером БД.
Система разрослась, масштабируете систему, добавляете вспомогательную систему управления этим масштабированием, его мониторинга и обслуживания.
Обратите внимание, что этот сценарий подходит для клиент-генерируемой логики и для логики, реализованной в ХП.
Это можно делать хранимками!
О том и речь, что вы делаете как хотите: запускаете SQL транзакцию с клиента или внутри ХП - за вас система сама сделает адресацию этой одной ХП на нужные сервера.
Два местоположения бизнес-логики нацелены на разные получения разных преимуществ, им присущих.
И выбор этот достаточно прагматичен.
Писать простую (ее больше) логику на клиенте быстрее и проще (в том числе за счет ОРМ, например).
Еще на клиенте пишут очень сложные преобразования.
Когда мы пишем на клиенте, мы надеемся (или предполагаем), что у нас не будет потребности оптимизировать SQL-запросы. А если и появится, то достаточно будет руками эти запросы написать.
Зато логика в ХП работает быстрее (запросы уже скомпилированы и, часто, имеют оптимизированный план выполнения, плюс экономится память на ряд обслуживающих процедур типа пула соединений, гораздо более простой системы прав доступа, избыточности протоколов и даже физических шин данных), но требует специальных знаний.
В данный момент реализация логики на ХП все еще быстрее клиент-сгенерированных запросов, хотя технический прогресс сокращает разрыв.
Но, даже начиная писать новую систему, я бы все еще подумал бы над выбором: ХП или клиентский SQL.
Аналогично, мы вставляем блоки кода на С, если нужна высокая скорость.