А вот меня один раз скорректировали. Без шуток, +25%. На позиции middle. Просил просто среднюю(на мой взгляд) по рынку, которую получил путём прохождения ~10 интервью, изучением вакансий и т.д. Получилось выше средней планки.
Правда под вопросом момент применимости этой концепции. Как раз, чтобы "не выстрелить" себе в ногу(читай не столкнуться с The Diamond Problem) в языках Java & C# появились интерфейсы и концепция их множественной имплементации.
Камилла Воронцова: придете на пары - увидите... Школьный курс надо понимать хорошо - для 1 семестра с головой хватит. P.S. Вопрос из разряда "ради вопроса"... Какие предметы знать, какие не учить - можно подумать если вы какой-то предмет не знаете ВООБЩЕ, вы его за три месяца выучите... Решайте задачи поступательно: поступили в универ, хотим учиться->понимаем, что не тянем->учим.
Iq51: я другое имел ввиду: ссылочные поля двух структур будут указывать на одну область(читай один объект) в куче. У тебя будет по сути один и тот же объект в двух инстансах структур. Следовательно, получение доступа к объекту из скопированной структуры - потенциально опасная операция. Выхода два: быть уверенным, что ты не копируешь структуры в проекте, или объявлять ссылочные поля в структуре как readonly - чтобы исключить возможность их изменения "извне".
P.S. ничего не понял про кашу с индеком на объект в массиве, и как связаны GC и shallow копии...
Не думали насчет перехода в Java/.NET? Иногда, встречается инфраструктура в компаниях, состоящаяя стека Java/.NET и 1C, между которыми прокинуты интерфейсы. В этом случае вообще можете стать очень ценным членом команды. P/S Может быть у вас просто депрессия? ИМХО, человеку потратившему 10 лет на автоматизацию слишком быстро наскучит стандартная "веб-студия".
eugene73: я исходил из условий вашего вопроса: поле в SQL создавать нельзя(об этом ниже). К тому же, вы хотите сделать это с помощью EF.
Теперь о поле. Ход мыслей у Вас конечно правильный(зачем нам новое поле - это ведь сумма строк). Но нужно понимать масштабы. Представим, что у вас какая-то финансовая система с документами. Когда Вам нужно сделать сводный отчет за год - вы будете пересчитывать каждый раз сумму. Для системы с 1 пользователем и 1000 документов - ОК. Для 1000 пользователей с 100 000 документов(количество строк документов еще больше) - уже нет. Здесь, выходит, гораздо оптимальнее хранить промежуточное состояние суммы в отдельном поле(вычислять его при записи/изменении документа). А если документ рождает проводки на постоянной основе(и вместе с ним тысячи других), а общая сумма падает в какие-то таблицы накоплений? А если она еще участвует в N процессах? Решать только вам. На заметку: никто в тяжелом Enterprise не приводит таблицы к 5-6 НФ. В одном случае подсчет поля"на лету" - это "cheap operation", в другом - уже нет.
Я лишь дополню, что не стоит бояться физики в подобных направлениях обучения. У меня с физикой были дела 50/50 - засчет русского языка нивелировал мои несчастные 69 баллов. Думаю, 60-70 баллов по физике, позанимавшись с репетитором, можно набрать.
За 6 лет что-то изменилось в МИФИ и там на безопасность уже не стали требовать физику для поступления?! Насколько я помню, физику требовали везде в моем случае(2010 год поступления) в т.ч. в МИФИ на КИБ. Неужели теперь требуют информатику? ЕГЭ по информатике - детский сад.
Роман: просто файл это костыли. Если вы сделаете сервис, который будет обновлять этот файл при изменениях в БД - то еще куда бы ни шло. Даже так это будет велосипед, ИМХО, не самый удачный, особенно для реального проекта. Да и несчастный этот Join для современной БД - вообще не проблема.
Роман: а почему бы не определить кастомную View, где и сделаете join? Я изначально с этой целью и ответил про information_schema. В моем случае сделал бы так, дабы не перетягивать логику выборку данных в код.
Но скорее это исключение из правил.