Евгений

SELECT
    table2.post_id as post id,
    table2.title as title,
    table1.deposit as deposit
FROM table2
    LEFT JOIN table1
        ON table2.title = table1.title//джойн по тайтлу; в зависимости от вида хранящихся строк возможно стоит делать приведение к нижнему регистру, удаление пробелов и т.д.

P.S. Лучше бы, если джойн выполнялся по индексированным числовым полям(в угоду производительности).

Строка вида: This is "bum" text. What a "nice weather" today с помощью .Split('"') разобьется на массив следующего вида:
[0] - 'This is'
[1] - 'bum'
[2] - ' text. What a'
[3] - 'nice weather'
[4] - ' today'
Каждый элемент массива с нечетным (if(min % 2 == 1)) индексом - слово в кавычках. Алгоритм довольно странный, на мой взгляд.

Audit Login/Logout - индикация начала/завершения сеанса взаимодействия пользователя с сервером(во время создания/завершения connection-сессии).
SQL:BatchStarting/BatchCompleted - индикация времени начала/завершения выполнения пакета. Под пакетом понимается набор одной или более T-SQL инструкций, передаваемых СУБД для исполнения в момент времени.
RPC: Completed(Remote Procedure Call) - индикация успешного клиентского подключения извне и выполнения процедуры/пакета.

Для анализа запросов достаточно отслеживать SQL:BatchStarting/Completed и RPC:Completed. Пользуйтесь фильтрами(имя пользователя, приложение), отбирайте наблюдаемые вхождения T-SQL перед началом трассировки.

В вашем случае Entity Framework отправляет SQL-Batch на сервер; обращайте внимание на CPU - загрузка процессора сервера БД, Reads - количество чтений, Writes - записей , Duration - продолжительность операции в миллисекундах(10^-3). При выгрузке результатов трассировки в БД(очень удобная опция для анализа большого количества операций) или внешний источник секунды уже будут с приставкой "микро" или же 10^-6. Под RPC:Completed у вас выполняются регламентные команды SQL-сервера по установке/разрыву соединения.

Полезные ссылки:
SQL Server Tech Documentation - со стр. 878 инфа по профайлеру
Batches

Первое, что я хочу сказать: инициатива развития должна быть непринужденной. Не все хотят действительно развиваться и прикладывать какие-то значимые усилия для этого.

Конкретно мое мнение: влиять на технический рост IT-специалистов нужно осторожно. Инженеры - это очень пунктуальная и ревностная(в проф. плане) категория людей. Сотрудники уже в компании, а значит имеют достаточный(по-вашему мнению) скилл. Уважающие себя программисты читают книги, ведут home-проекты, где оттачивают навыки(я, надеюсь, у Вас именно такие:)).

Идти нужно от простого: что есть отрицательного в работе => подавляет энергию => не хочется творить => не развиваешься. Недопонимание между операционной и технической командами? Потому что первые постоянно закидывают мозговыносящими задачами, а вторые, исправляя баги, добавляют новые. Ты в "ынтерпрайзе" и ограничен в своих действиях, ибо никто не хочет внедрять "по свистку" новый фреймворк(надежность в угоду моде)? Менеджер снова завалил какими-то непонятными задачами и т.д., сделав которые, понимаешь, что их можно было по-другому сгруппировать? Можно продолжать... Часть этих проблем можно решить нормальной, здоровой коммуникацией(иногда стоит пойти на жертвы среди сотрудников - было у меня и такое).

Я не менеджер. Расскажу о 3-х летнем опыте(со старших курсов универа), который был стартом мой карьеры. Определенно, многому научился тогда. Исходные данные, чтобы было понятнее: организация(иностранная, если это будет важно) с представительством в РФ, Отдел внедрения IT.

Эту фразу нужно будет поместить на место трех точек в каждом пункте("..."):
Не каждому сотруднику это нужно, но обязательно найдутся те, кому будет полезнее именно так.

Что мне со стороны сотрудника показалось важным для роста:
0. Толковые тимлиды/архитекторы, готовые делиться знаниями - таких нужно выискивать и направлять их на менее опытных. Я в свое время с бешеной скоростью впитывал знания от старших товарищей. Команда сильна насколько силен самый слабый(и прочие бла-бла). Во-всяком случае, меня их уровень подстегивал. Это важный фактор, как ни крути. Должны быть лидеры(кстати, не только технические).
...
1. Прозрачная система ведения бизнеса. Это значит, что информация о том, что происходит в компании на поле битвы(бизнеса) доступна и понятна каждому сотруднику безотносительно его должности. Хочет программист/тестировщик знать как дела обстоят с новыми клиентами, в каких тендерах участвуем - пожалуйста. Но без фанатизма и раннего открытия информации. Какие настроения у текущих клиентов? Какие внутриорганизационные моменты происходят?...
...
2. Каждый сотрудник может спокойно организовать one-to-one с менеджером. Поговорить о выполняемых задачах, подвести итоги, обсудить какие-то планы на будущее(по бизнесу, по своему привлечению к будущим проектам, по возможному росту, по текущим задачам коллег). Сотруднику становится проще понимать прикладную составляющую своего труда и выдвигать свои идеи и предложения(разумно). Менеджер знаком с настроением каждого члена команды => распределяет задачи более оптимально, ну и в целом легче ему становится "дергать" нити управления.
...
3. Как можно более индивидуальный подход в "конвейерных" тренингах. К примеру, занятия English: вот походили мы с ребятами на корпоративные уроки - но это было больше похоже на курс для галочки(большинство "учащихся" на абы как, учителю как ни старайся...). А время шло, и я в N-ый раз уже слышал менеджера "на колле" с иностранцами. Тут родилась идея объединиться в группу с тему, кому действительно ХОЧЕТСЯ и найти себе преподавателя из школы. Сказано - сделано. Больше года занимались с отдельным преподом, который к нам приезжал в офис. Потом даже выбили себе немного бюджета на это c помощью менеджера(не 100% покрыли конечно). И в итоге все довольны - мы знаем английский(главное, что потом и применять стали), у компании, соотв., тоже одни плюсы.
...
4. Давать сотрудникам иногда чуть более важные задачи, чем они привыкли делать. Давать вистов иным образом. Здесь конкретные примеры сложно привести. Допустим, взять программиста в командировку на локацию на этапе оценки инфраструктуры и знакомства с клиентом. Хотя он там не особо-то еще нужен. Или в конференцию его подключить по важному вопросу. Нужным людям это даст больше уверенности и мотивации, и они сами будут готовы генерировать идеи во благо, без палки даже.
...

P.S. Я уже не там, да и вообще круто(от слова "резко") поменял стек технологий. Но ценю тот опыт, который смог там получить.

Создать partial класс для сущности Document под именем Document.MyExtensionBlaBla.cs; добавить в него новое свойство TotalQuantity и определить логику его вычисления:

public partial class Document
{
     public decimal TotalQuantity => Rows.Sum(x => x.Quantity)
}

Впоследствии, к этому свойству можно обращаться из инстанса Document. Например, так:

var totalSumByDocument = new dbCtx().Documents.Single(x => x.Id == id)).TotalQuantity;

Где id - входной параметр искомого документа, представляющий собой его уникальный идентификатор.

Цикл жизни статичных переменных определяется циклом жизни приложения - это уже один минус. При перезагрузках вашего приложения нужно будет их восстанавливать. В случае хранения идентификационных данных в Session, либо в Db - этим моментом управляете Вы, определяя цикл жизни этих данных.

Статичные переменные доступны только на одном сервере. Если Ваше приложение хостится на нескольких машинах, то опредленные переменные на одном сервере не доступны с другого.

Статичные переменные доступны всем, т.е. являются глобальными в рамках App Domain. Думаю, это тоже о многом говорит. Придется делать костыли, боюсь представить какие, по доступу к ним; как-то параллелить клиентские запросы. В то время, как для Session есть Session concurrency

В целом, если говорить об механизме Session, то скажу, что это понятные и широко распостраненные практики хранения идентификационных данных. Думаю, для большинства прикладных задач это вполне применимый подход. Если требуется больше безопасности, то уже смотрим в сторону Server-side для хранения состояния, например, в БД.