Дмитрий Ковальский

Как правило вся нагрузка соберется на сервере БД. А там, помимо типа бд, хватит тонкостей даже с банальными выборками. Инструменты? Главная задача - выявлять узкие места. Профилировщик сервера бд к примеру может стать весьма полезен.

return vector<string>(); вам ничего как бы не должен в указанной реализации.

Есть слегка устаревшая статья на эту тему. Возможно она ответит на ваши вопросы.

Справедливости ради - вашего решения мы тоже не видим)) Критерии могут быть самые разные. Использовали вы или нет транзакции, использовали вы или нет блоки try/catch. Взяли курсор или избыточный FULL JOIN. Или наполнили код IF ELSE , а хотелось одним запросом... Но как ответил Сергей - Один случай действительно не показателен. Продолжайте искать.
UPD: Оглядел поверхностно ваш код и в целом понимаю заказчика. Грехов хватает.

set @flag_item	= (select [1] from #tmp_insert where [0] = @i)
set @flag_in	= (select [2] from #tmp_insert where [0] = @i)
set @flag_out	= (select [3] from #tmp_insert where [0] = @i)
set @flag_count	= (select [4] from #tmp_insert where [0] = @i)

За такое мой руководитель меня распнет и оставит на солнце голгофы.

SELECT @flag_item = col1, @flag_in=col2,@flag_out=col3, @flag_count=col4 FROM #tmp
WHERE col0 = @i

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

Кстати - вы откатываете транзакцию при определенных условиях. А что за транзакция? нету риска что вы откатите некую параллельную нормально функционирующую?

docs.mongodb.org/ecosystem/drivers/csharp - Аж оф.сайт проекта MongoDb. с документацией и примерами. Не подошло?

Любая схема имеет право на жизнь, пока не начнет безбожно тормозить. Как уже успели заметить в комментариях - Зачем? Вы фактически вместо одного запроса - делаете 2 и в разные источники. Что вам мешает создать таблицу products_description и в ней хранить 3 поля - product_id , locale, и данные в xml или json формате? На вход хранимке 2 параметра - id и локаль , на выход все необходимые данные для постройки формы. Причем если на уровне базы данных целостность внешнего ключа проверять не составляет труда, то как вы собираетесь контролировать данные в двух разных источниках?

смотрите через devtools ошибки. скорее всего проблема в путях к нужным файлам.

довольно путаное объяснение задачи. вам нужен или сложный select для четкой выборки что добавлять или "курсор"

Ну если у вас нет ограничений на размер файлов скриптов, да и минимизатор используете - то не страшно. Хотя привычка странная.

Попробуйте так

SELECT id,SUM(кол-во)
GROUP BY id
HAVING SUM(кол-во) > someValue

А банальное source[0] to UpperCase не работает?

99,9% - у них НЕТ поиска по сайтам авиаперевозчиков. Есть договор обмена данными через некое API

for (var i = 0, le = rsrGroups.length;
le - это опечатка?

Что вы реализовываете? Зачем эта функциональность? В теории все решается скриптом grant "' on table1 to user1 или внешним ключом на таблицу users. Но в целом попахивает бредом. пользователи не должны иметь доступа к бд, и уж тем более индивидуального. Хотите поадминить? дайте им собственную базу и пусть измываются как хотят