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

Объясните пожалуйста структуру вашей сущности. На мой взгляд сопоставление album_id - filename достаточно для однозначного уникального определения обложки альбома. В вашей таблице есть еще 2 идентификатора сверху. Вы предлагаете каждому пользователю грузить желаемое изображение? ок, тогда зачем еще один id? как ваша таблица называется тогда? Данная структура не нормализована. По факту вы на ровном месте увеличиваете объем данных в базе и если это нужно для отчетности - тогда ок, но если это так и задумано - надо преобразовывать одну таблицу в 2-3, в зависимости от сути сущности.

Можно взять 2 таблицы и попробовать сделать INNER JOIN по полям, которые должны пересечься.

Если вы хотите услышать ответ в форме - "в 2", "в 5", "в 1,5" то вынужден вас разочаровать. EF это витиеватая сложная обертка над ADO.NET сделанная с единственной целью - сделать вашу жизнь чуть попроще если вы плохо знакомы с техникой работы с базой данных. Технически она генерирует SQL запрос на основании ваших писулек и исполняет его на базе теми же классами и методами ADO.NET что и вы. Если вы хорошо пишете SQL-скрипты то разница в производительности будет только в обертках. Если вы хреново пишете скрипты и лепите курсоры, лишние JOIN-ы и еще ворох странных инструкций - то лучше возьмите EF. Если вы хреново пишете и серверный код, где сначала тащите всю таблицу данных к себе на сервер приложения, там ее фильтруете и сортируете, а затем отрезаете нужный кусочек - то вас и EF не спасет. В таком случае сгенерится фантастически неэффективный запрос с, возможно вынужденными, доп. запросами и при этом еще и само приложение получит задачи, которые ему даром не нужны. Нет хорошего ответа вроде "при миллионе записей пиши руками, а если меньше EF". Надо глобально смотреть на архитектуру приложения и взаимодействие с данными.

Да, есть решения проще и если бы вы добавили теги клиентских скриптов( javascript, jquery) то получили бы ответ раз так в 10 быстрее. Существуют события onunload и onbeforeunload. Они не слишком кроссбраузерны и кое где могут не работать, но это будет проще чем костылить SignalR.

Поскольку в mysql нет инструкции PIVOT, есть такие вот решения - stackoverflow.com/questions/7674786/mysql-pivot-table

А почему не таблицей "Оборудование в регионе"? id девайса, id региона.

Шилдт считает что вы дерево, севшее за IDE второй раз в жизни. Троелсен считает что вы сидели уже раз 5 и способны написать Hello World, цикл и ветвление и вам нужны только причуды платформы. Вы дочитали до главы 3. И как самочуствие? Понимаете что там написано? Если да - то продолжайте без страха.

Ну и постановочка вопроса у вас.
http://jquery.page2page.ru/index.php5/Скрыть_элеме...

Ну регистр вы и сами поднять можете - не перелометесь и бросать ошибку об этом, наверное, не стоит. А сами буквы проверяются регулярками - причем довольно простыми. Если у вас совсем плохо с ними - https://regex101.com здесь можно потренироваться.

Простите, а вы на WebForms работаете? Чем вам не угодил ASP.NET MVC умеющий в ЧПУ архитектурно из коробки?

DECLARE @id1 INT;
DECLARE @id2 INT;
SELECT @Id1 = id1, @Id2 = id2 FROM table1 LIMIT 1

Так работает? на MS SQL точно можно. В зависимости от того что вы с этой выборкой дальше делаете - вполне возможно что можно найти более изящное решение( например сохранить во временную таблицу и в последствии JOIN-ить ее к вашим запросам.

В двух словах - это невозможно. Чуть более длинно - stackoverflow.com/questions/17499351/is-it-possibl... .
Потенциальное решение - стимулируйте пользователей обновлять систему. Что поддержка данной операционки усложняет и удлинняет процесс разработки и тестирования новых фич, а соответственно увеличивает стоимость продукта.

А зачем вам phome_model связывать с организацией? Более того - я не вижу там полей для связи ни в одной ни в другой таблице. Если вы под id подразумеваете внешний ключ на какую-то таблицу - то будьте добры назвать его соответствующе.
Почему в таблицу employee нет внешнего ключа на organization? через какую сущность я смогу получить всех сотрудников организации?
Где связь сотрудник-телефон?
Ну и поясните в двух словах - то что у вас телефон связан с моделью телефона я вижу, а как модель телефона связана с организацией и сотрудником я не наблюдаю в принципе(да и зачем их связывать?!).

Попробуйте использовать SQL подобный синтаксис. Возможно станет понятнее что как JOIN-ится

var temp = from t in A
                  join b in B on t.Site = b.Site AND t.C = b.C
                  where condition
                  select what you need

Большими буквами помечены коллекции, маленькими - alias.

Ну на таблице Users с полями "login, password" свет клином не сошелся. Добавляете таблицу вроде UsersInSocial где храните привязки UserId и данные учетки соц.сети связанной с этим пользователем. При аутентификации по второй таблице уточняете кто это.