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

SELECT/INSERT/UPDATE/DELETE и JOIN-ы не изменились. Большая часть работы с SQL - виртуозное владение этими командами.

А можно в двух словах описать бизнес-логику? Я под страхом смерти не пойму зачем удалять строку после ее обновления. Если вы хотите проверять что было проставлено isDeleted и исходя из этого - удалить строку, то это решается не триггерами, а разовыми запросами
delete from table where isDeleted = 1
где нибудь в 3 часа ночи, когда клиентура спит. Хотите удалить сразу? Удаляйте сразу.

SELECT id, CASE   WHEN t1.activity = 0 THEN t2.activity ELSE t1.activity END as activity 
FROM t1
LEFT JOIN t2 ON t1.id = t2.id

Однако следует понимать что если в t1 будет 0 , а t2 отсутствует - то в выдаче будет NULL, но это решаемо.

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

Для одиночных инструкций(одного запроса SELECT,INSERT,UPDATE,DELETE) существует альтернатива - Обобщенные табличные выражения(CTE) - link

Разумеется если временная таблица вам нужна больше чем на 1 запрос - такой подход неприменим.

По хорошему такие телодвижения должно делать приложение, а не одна база в другую запросы слать(да еще и меж серверов). Но если прям вообще невтерпеж именно так реализовать - stackoverflow.com/questions/70455/cross-server-sql тут есть пара вариантов. Ну и вообще гуглить заклинание "cross server sql"

Проблема в том что вы сделали "множество таблиц, абсолютно абстрагированных друг от друга".
А они такими быть не должны. Делайте множество подобных запросов к каждой таблице или нормализуйте структуру и можно будет уже писать что-то более конкретное. Если таблицы не "абсолютно абстрагированны друг от друга", то их можно объединять через JOIN и делать 1 запрос вместо 10.

Как вариант

select id from products as p
INNER JOIN productPropertys as type ON type.product_Id = p.id and type.value = 'ель'
INNER JOIN productPropertys as length ON length .product_Id = p.id and length .value = '200'
INNER JOIN productPropertys as someOtherProperty ON someOtherProperty .product_Id = p.id and someOtherProperty .value = '10'

select what your need from orders_list as ol
INNER JOIN goods as g ON g.id = ol.good_id
WHERE --условие на дату
GROUP BY g.id, g.name

LINQ2SQL лучше вообще не использовать, особенно в команде на сколь нибудь крупном проекте.
EF - Рекомендуется для повсеместного использования в качестве ORM с небольшой сноской - если в вашем проекте нет требований по производительности взаимодействия с БД и если вы хотите быстро быстро на коленке сваять уровень взаимодействия с базой.
Для более эффективного взаимодействия с БД рекомендуются тонкие обертки над ADO.NET с вызовом хранимых процедур.

Уточните пожалуйста логику. Вы запрашиваете во View поле, которое задано как строка в 20 символов(не более) и хотите чтобы она стала строкой в 50 символов.Я вас правильно понял? если да, то вы понимаете что это просто заполнение памяти мусором? Объясните вашу проблему - пока я не могу сходу представить ваш сценарий, требующий такой реализации.

Я может чего-то не понимаю. А что вам запрещает сделать выборку по всем нужным type, а затем разгребать данные на уровне приложения? Зачем тут union и множественные типовые запросы?

Вариант написать хранимую процедуру с транзакцией добавления данных с нужными проверками не рассматриваете?