Здравствуйте, Mr.Delphist, Вы писали:
MD>Мне это напоминает измышления "язык высокого уровня vs ассемблер". Когда-то тоже казалось, что асм форева, а всё остальное для поделок на коленке. Однако поди ж ты — уже выросло поколение, не знающее почему 'xor Ax,Ax' лучше чем 'move Ax,0'
Ишь ты! Во-первых xor ax, ax только ситуационно лучше, чем mov ax, 0, т.к. портит регистр флагов, а посему имеет меньший потенциал применимости (параллельное исполнение, зависимые команды). Конечно, на Z80 это был лучший выбор всегда, когда нас не интересовал регистр флагов.
Но, все таки сравнивать это мне кажется не совсем корректно, и даже бессмысленно: EF CF придумали люди которые никогда в жизни не видели объемных БД (по числу объектов), модульных (в разных деплоях — разный набор объектов, а приложения лишь знают о своих объектах), и просто не понимают, что апгрейд (с изменением структуры) — это процесс, который требует культуры и подготовки, а именно, бэкап до, апгрейд, деплой, боевая проверка. Апгрейд с весьма ненулевой долей вероятности может обломиться, по причине того, что разработчики не учли всего, и конверсия данных сдулась на ровном месте, или уборщица обесточила серверную. А может и просто кривую версию выпустили всего — необходимо откатить, т.к. за оставшееся время на обслуживание ясно, что систему не запустить. Как потом восстановить тот хотя бы гигабайт данных, который испорчен? При этом эта процедура могла затрагивать много объектов, и ни в какую одну транзакцию оно не влазит, никакой "транзакционности" невозможно, если не хочется что-бы апгрейд занял двое суток, на что бизнес, естественно не пойдет. Это сугубо административный процесс. Я тут безусловно местами утрирую, но тем не менее, мы как-то делали мажорный апгрейд где чистое время работы сиквела на конвертацию — около 8 часов. Это очень большое время, это же не за пару секунд напедалить и попробовать.
Потом появился SSDT который дал даже готовые тулзы из коробки которые хорошо работают. Хотя мы и без него неплохо обходились, местами со своими довольно простыми тулзами.
В итоге, мне лично проще делать "database-first", с нормальными генераторами классов, навроде linq2db, а не в стиле EF.) Либо, если данные БД можно легко воссоздать (для тестов например) — то её проще переподнять полностью, и закачать туда данные.
Опять же, т.к. БД работает не на водороде, то ее проектирование — это важный этап. И мне глубоко пофигу, если в EF/клиенте неудобно получить желаемую пропертю, т.к. структура выбирается исходя из соображения необходимого баланса между потребностями запросов и занимаемого пространства, с уклоном в скорость запросов, и тут далеко не всегда работает нормальная форма (без фанатизма, но некоторые данные выгоднее "перегруппировать" так, что бы меньше было строк, хотя бы за счет роста таблицы в ширину.)
Т.н. code first позволяет пропустить кучу шагов, не зацикливаться, и тому подобное, но в финале, я наблюдал это только так, что люди писали там марсианские классы, которые потом приходилось переделывать полностью, более, чем в три раза: структуру БД, в результате получается 10-100х уменьшение хранимого мусора, и даже уже в следствии этого — ощутимое ускорение, само по себе ощутимое ускорение потому как... сделано не идеально, но с любовью, и весь связанный клиентский код, который вместо безбожной дури творит, то, что его просили, давая суммарный выигрыш в абсолютных числах около часа (задача начинает выполняться внезапно 5 секунд, а лопатит несколько млн строк). Ну и естественно, эта работа не бесплатно достается работодателю.
Есть еще историй много, где вместо дурацкого кластера со всеми модными наворошками всего-то надо было правильно поднять и настроить ровно один сервер. Но это из области "не интересно". Зачем делать правильно БД, если вместо этого можно поднять кластер мутни по которой даже статистику без приседаний не соберешь, а клиенткая библиотека в асинхронном вызове использует блокирующую очередь, чего на трэд пуле делать не очень хорошо, вплоть до дедлока сервера, когда в ответ на голодание, рантайм откажется спаунить новые потоки.
Мои байки — конечно, достаточно экстремальны по своему характеру, но нажиты личным опытом.
В общем, очень плохо, что новое поколение не знает разницы между xor ax, ax и mov ax, 0 и/или каких-то базовых фундаментальных вещей.
PS: Хотя, я конечно согласен, что для определенного класса задач EF CF применим, но это всё же это нишевой и замкнутый подход. А преподносят красивыми словами-то какими... И C/C++/C# vs asm тут не идет ни в какое сравнение, потому, что CF — это такой своеобразный brainfuck. Вроде как и язык, да не то...
