Dmitry V. LiseevЛадно. Начнем с начала. Вот есть у нас система. Очень
сложные данные с кучей зависимостей и констрейнов.
Очень сложная логика. Логика такая сложная, что большинство
нужных нам операций одним SQL запросом выполнить
не получается. Даже прочитать нужные нам данные
одним запросом не получается. Знаете, я не Станиславский, но вслед за ним скажу "Не верю!". То, что вы сейчас описали не бывает никогда , за исключением одной единственной ситуации - очень криво спроектированная структура данных.

Dmitry V. LiseevА нам нужны транзакции
и логическая целостность данных. И вот мы с клиента
стартуем транзакцию, получаем ответ, что стартовала
успешно. Посылаем запрос, получаем ответ, что
все хорошо. Повторить предыдущее предложение N-раз.
Потом фиксируем транзакцию если все было успешно
или откатываем при ошибках.
В чем у нас тут проблема? Если канал связи медленный,
модемный, или куча юзеров сидит на общей шине не
на свитче, а на банальном хабе, то это все по сети
гоняется медленно. Да пока клиент эти запросы
формирует, да пока переваривает ответы. Короче,
транзакция затягивается.Клиент переваривает ответы во время транзакции? Словосочетание "хранимая процедура" слышали когда-нибудь?

Dmitry V. LiseevЧего в этом плохого? Плохо тут то, что транзакция
лочит данные, которые она затрагивает. И все остальные
юзера работать не могут, а просто ждут, пока транзакция
не закончится или не откатится. Понятно, что какой бы
навороченный сервер мы не поставили, он просто будет
простаивать в ожидании снятия блокировок, а ускорить
такую сложную транзакцию никак не сможет, ибо причина
в том, что тормозит клиент и его канал связи. Самое ужасное,
что для возникновения проблемы достаточно, чтобы тормозили
всего несколько клиентов из сотни. А дальше - цепная реакция.
Клиенты ломятся на сервер, пересекаясь по данным,
количество блокировок нарастает, в целях экономии ресурсов
(ибо размер буфера, где хранится информация о блокировках
быстро растет, пожирая память, следовательно лочить надо
более крупными кусками, тогда записей будет меньше, в идеале
нужна одна запись "залочена вся база целиком")
сервер применяет эскалацию блокировок, то есть лочит не
только записи, непосредственно затронутые транзакцией,
но и целиком страницы и даже целые таблицы, блокируя
рядом оказавшиеся ни в чем не виновные записи. В итоге
вероятность очередного клиента влететь на блокировку
еще больше возрастает. Скоро транзакции, так и не дождавшись
заблокированных данных, начинают отваливаться по таймауту.
Алгоритмы тут в разных СУБД разные. Некоторые работают
по принципу: "Кто раньше встал, того и тапки". Т.е. чья транзакция
началась позже, та и отлетит в случае конфликта. Другие поступают
умнее. Они замеряют, сколько ресурсов уже пожрала транзакция.
Понятно, что ту, которая стоила кучу сил серверу, убивать жалко,
потому прибита будет та, что меньше "стоила".
У меня такое ощущение, что Вы рассказываете о MSSQL Server
Dmitry V. LiseevСмотрим, почему транзакции лочат данные и чем "сложные" данные отличаются от "простых". Допустим, есть у нас таблица.
Куча юзеров могут параллельно в ней что-то делать, добавлять,
удалять, менять. Допустим, к одним и тем-же записям разные
юзера не обращаются. Понятно, что юзера друг-другу не мешают.
При очень быстром диске и мощном сервере юзеров может быть
очень много. Но вот мы захотели, чтобы был констрейн. Допустим,
хотим, чтобы одно из полей в таблице было уникальным.
Тем самым мы ввели неявные зависимости между разными
записями в одной таблице. Допустим, первый юзер стартует
транзакцию и удаляет запись со значением "ААА". Второй
юзер пытается вставить запись со значением "ААА". Можно
или нельзя? Все зависит от первого юзера. Он может как
подтвердить транзакцию (запись исчезнет и второй сможет
вставить свою) так и откатить транзакцию (запись вернется
назад, а второй юзер получит ошибку). Соответственно, второй
юзер должен быть залочен, пока первый не закончит свою
транзакцию. Аналогичные рассуждения можно привести
и для внешних ключей, когда возможность существования
записи с FK в одной таблице зависит от наличия записи с
PR в другой таблице. Т.е. тоже неявные зависимости.
В итоге мы понимаем, что чем больше констрейнов и FK,
т.е. чем более "сложные" данные у нас, тем больше записей
может быть заблокировано каждой транзакцией и много юзеров
уже не могут работать параллельно. Вообще, вопросы
изолирования транзакций и стратегии блокировок описаны
в специальной литературе.А про отложенные проверки целостности слыхали? Хотя, конечно, судя по тому, что Вы тут рассказываете, Вы, вероятно, уже нашли серебряную пулю

Dmitry V. LiseevСтановится понятно, что необходимо транзакции проводить
как можно быстрее, данные проектировать так, чтобы
зависимостей было как можно меньше, уменьшать вероятность
обращения юзеров к одним и тем-же данным. Если бы клиент
не управлял транзакцией сам, а мог бы передать на сервер сразу
все необходимые для нее данные одним пакетом, то транзакции
не затягивались бы, а медленный канал был-бы проблемой
только этого клиента и не лочил бы всех остальных. То есть нужен
принцип "один пакет - одна транзакция". Аналогично,
было-бы хорошо, если бы все нужные для отображения данные
передавались бы с сервера на клиент также одним пакетом.Правильно, не пойму только, почему бы так и не поступить?

Dmitry V. LiseevКак это сделать? Можно построить "трехзвенку на основе
двухзвенки". То есть данные, нужные для начала транзакции,
клиент неспешно засылает в разные временные таблицы,
никому не мешая.Точно, MSSQL Dmitry V. Liseev Потом запускает хранимую процедуру,
которая и проводит как можно моментальнее всю транзакцию,
а результат выдает в другие временные таблицы. Клиент,
опять никому не мешая, неспешно их оттуда забирает.
В итоге мы получаем сервер приложений на ХП.Так, словосочетание знаете, готовить не умеете.

Dmitry V. LiseevНо гораздо интереснее, все-же не гонять по сети кучу
пакетов, да еще через временные таблицы, а сделать
более нормальный СП. Понятно, что нам мешает "бедность
SQL", который не дает выполнить сложные вещи одним
запросом, а кучу сложноструктурированных данных
нельзя передать параметром в ХП, оттого мы вынуждены сначала
засылать их в кучу временных таблиц. Точно не умеете :((

Dmitry V. LiseevПотому наш СП
будет принимать от клиента сложноструктурированные
запросы и отдавать сложноструктурированные ответы.
Хотим, гоняем в формате XML, хотим, сериализуем в свой
компактный бинарный поток, да еще и зипуем, если с трафиком
совсем тяжко.Ну-ну. Любители модных аббревиатур.

Dmitry V. Liseev Важно, что один пакет - одна транзакция.
Даже, если канал медленный и клиент тормозит - не беда.
Важно, что это не мешает остальным и не затягивает
транзакции.

А с другой стороны наш СП имеет толстый канал связи
с СУБД. Совсем физически независимая сеть, даже
отдельная сетевая карта, чтобы никто не мешал ему
как можно быстрее провести транзакцию.А если работать с сервером напрямую, через ХП, то никакой независимой сети вообще не нужно. Не говоря уж об отдельной сетевой карте

Dmitry V. LiseevУ-ф-ф, руки устали.Наши руки не для скуки(С)

Dmitry V. LiseevУ нас нет dll. Сервер приложений полностью на скриптах. Поставляется
заказчику целиком в хорошо откомментированных исходниках. Если
заказчику нужен новый отчет или слегка измененный старый, он делает
копию существующего, исправляет и компилирует прямо на сервере
приложений. При запуске этот отчета генерит XML и отправляет
на клиента по медленному каналу связи. Клиент пускает XSLT
и получает XSL-FO, на который натравливает FOP
и получает красивый PDF. Ловкость рук и никакого волшебства.Интересный подход. А если не отчет, то тоже может исправить в хорошо откомментированных исходниках ? А отвечают за это рукоблудие, насколько я понимаю, другие разработчики (см. ниже)
Dmitry V. LiseevЕсли заказчик не может сам сделать отчет, то просит нас.Скорее, не "если", а "когда". Когда испортит все до такой степени, что исправить будет сложнее, чем написать все заново.

Dmitry V. LiseevПроектировалась мной лично с нуля. Я занимался реализацией
всей серверной части. Клиентские части делали другие
разработчики. Приход меня "на готовое" обычно сопровождается
полным перепроектированием системы. Я это обычно сразу
уточняю при приеме на работу ;) На поддержку готового нанимают
сисадминов, а я - проектировщик.Тоже знакомый подход. То, что было раньше, в корзину, потому что у меня свой взгляд на мир. Я только бумажку с красивыми и умными словами напишу, а что в результате получится - это не мои проблемы, для этого есть другие разработчики .