d-stream

Ну если есть уверенность в подготовке полностью идентичного клона и допустимое время простоя соизмеримо со временем перетыкания разъемов - то это наверное самый оптимальный метод.

гм... берем какой-нибудь многополосный эквалайзер, включаем музыку и выводим все ручки в самый низ, а одну самую низкочастотную - вверх. В итоге слышим только бум-бум. Потом выводим так же только самую высокочастотную - слышим псс-псс, потом выводим ручку в районе 1-3 кгц - слышим голоса певцов

Вот простейшая иллюстрация частотной фильтрации: из кучи разных частот - выделяем что-то одно.

Или как еще один вариант: делаем музыку погромче и ставим камертон рядом с динамиками - он будет вибрировать (резонировать) в такт с наличием ноты ля первой октавы, если таковая встретится в музыке.
Ставим рядом другой, экзотичный камертон на ре второй октавы - он будет звенеть на соответствующие ноты.
Если теперь попросить одного музыканта "морзянить" на ля первой октавы, а второго на ре второй - то этими двумя камертонами можно отделить одну морзянку от другой.

WPF - это очень отдельное и можно сказать далекое от web дело.

Так что или asp.net и MVC или же XAML и MVVM

Ну и стоит иметь в виду, что на дворе уже C# 7, поэтому стоит ориентироваться на хотя бы версию 6 (это конечно не самое критичное, но все же)

case when SUM(Plan) < SUM(Fact) then 0 else SUM(Fact)/SUM(Plan)*100 end

только я бы наоборот писал

case when SUM(Plan) >= SUM(Fact) then SUM(Fact)/SUM(Plan)*100 else 0 end

Вполне нормальная структура. Можно еще заменить признак прочитано/нет на nullable дату прочтения

Еще как вариант: держим пользователя до активации в черном теле, оставив ему собственно возможность править свой e-mail и отправлять активацию снова.

Ну и понятное дело - срок годности активации и ограничение на число и частоту смен почты и повторной активации.

Для самого начала не помешает озвучить что за маршрутизатор(ы) используются. У большинства НЕдомашних как правило в описаниях, примерах приводятся варианты балансировки каналов, мониторинга и динамического переключения маршрутов и т.п.

Как уже CityCat отметил про AS - пропускаем. А так: раскидываем каналы по вкусу (например по сервисам, приоритетам, нагрузкам) и мониторим доступность "вечного" ресурса через разные интерфейсы. В случае падения - динамически меняем маршруты или их метрики на второй канал

Стоит попробовать переключить кодировку (chcp unicode или chcp 65001)

Универсального нет. Выше вариант наводки дали, но это не всегда и не везде.
Посему наверное единственный универсальный вариант - наличие третьей стороны (сервера). Остальное - уже по вкусу:
- все взаимодействия через сервер (типа Hamachi, ammy и т.п.)
- сервер работает только сводником (торренты)

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

На мой взгляд озвученная задача вполне вписывается в классику реляционных структур:
id, порядковый номер параметра, значение параметра
или даже
id, порядковый номер параметра, тип параметра, значение параметра

соответственно тогда все вкусности сортировки, группировки, агрегирования, поиска - будут доступны во всей красе

C учетом того, что народ подобное запускает на девайсах чуть мощнее бухгалтерского калькулятора - вполне потянет все кроме воспроизведения и рекодинга видео.

Не проще ли сделать left join ?

Ничего не надо, просто переводим:

field_id = 805312 и field_value = 1417294800, и запись с field_id=805316 и field_value=2126254.

в
where
(field_id = 805312 and field_value = 1417294800)
or
(field_id=805316 и field_value=2126254)

Скобки лишь для акцентов