LINUX.ORG.RU

История изменений

Исправление Toxo2, (текущая версия) :

А можете пояснить:

Допустим есть некоторый расчет. Ему требуется сдернуть данные с десятка таблиц и внести изменения в пару-тройку. В один SQL-запрос не влезает.

В чём преимущество иметь возможность легко масштабировать бэкенд перед возможностью написать одну хранимку? Эти сотни бэкенд-коннектов всё равно же пойдут в ту же БД? И как на этих независимых коннектах отслеживать блокировки?

По-моему - единственное, чем должен заниматься бэк в таком случае - каким-либо образом знать надо ли вообще БД дергать, может в расчете ещё ничего не поменялось и можно отдать из собственного кэша готовое.

Исходная версия Toxo2, :

А можете пояснить:

Допустим есть некоторый расчет. Ему требуется сдернуть данные с десятка таблиц и внести изменения в пару-тройку. В один SQL-запрос не влезает.

В чём преимущество иметь возможность легко масштабировать бэкенд перед возможностью написать одну хранимку? Эти сотни бэкенд-коннектов всё равно же пойдут в ту же БД? И как на этих независимых коннектах отслеживать блокировки?