Может просто написалово объявления поручено исполнителю который не знает что такое существует?

Максимум, что делает рекрутер - меняет форматирование требований. Требования рекрутер получает от тимлида, который набирает к себе к команду.

А можно попытаться разобраться самому.

------

Для работающего с базой через ОРМ занятие достаточно бесперспективное - генерируемый SQL и ошибка очень малоинформативны в вопросе процессов в базе.

"Кодописатель" знает.

-----

Этого достаточно чтобы перестать рассматривать предложение.

Тестер знает.

-----

Если так - он уже не тестер.

тесру может быть необходимо исполнять уже написанные кем-то SQL-запросы. Кроме того, ему может быть необходимо вносить какие-то минимальные изменения в существующие запросы

------

Где и зачем в ЕГО работе это требуется?

Очевидно, что

-----

у тебя сложности с пониманием написанного по-английски.

Особенно если что-то подчеркнуто или еще как-либо выделено.

Требования рекрутер получает от тимлида, который набирает к себе к команду.

------

Ой...

Ну и нахрена лезть куда-то, где требуется знание T-SQL для Оракла?

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

Этого достаточно чтобы перестать рассматривать предложение.

Ну вот ты и не можешь найти ничего подходящего ;)

Если так - он уже не тестер.

С фига ли? Конечно и тестер и разработчик всегда знают что там за БД "под капотом".

Где и зачем в ЕГО работе это требуется?

Ну например затем, чтобы держать в актуальном состоянии "ожидаемое состояние БД". У нас на одном из проектов были именно такое системные тесты. Тест проходил по такому сценарию: 1) инициализация БД (запускался sql файл с сотней разных sql запросов, которыми создавалась БД и наполнялась начальными данными) 2) запускалось приложение на выполнение определенной задачи 3) делался дамп БД и сравнивался с ожидаемым дампом.

И если создание БД было обязанностью разработчика, то наполнение данными и поддержание ожидаемого дампа в актуальном состоянии было обязанностью тестера.

у тебя сложности с пониманием написанного по-английски.
Особенно если что-то подчеркнуто или еще как-либо выделено.

Неее, проблемы с пониманием таки у тебя :)

Ты же задаешь рекрутерам тупые вопросы, а не я :) Для меня в этом объявлении все очевидно - изут full-stack разработчика (инструментарий: .Net, C#, MVC, JS и MSSQL2019), Task Tracking и (возможно) система контроля версий - Azure DevOps (aka TFS), через нее же у них CI/CD.

всегда знают что там за БД

-------

Гы...

Шо,ни разу не случалось писать не зная что там будет?

Может было хотя бы больше одной?

Тест проходил по такому сценарию

-----

Ой...

А компостер там включали?

Оставь скрипты и транспорт в покое - первых вообще нет - есть ОРМ, а второе УЖЕ признано рабочим

Но даже если принять его - работа тестера не предполагает фиксинга - только выявление проблем.

через нее же у них

-----

Им осталось найти того кто сможет ЭТО грамотно описать.

А пока маркируем отсутствие грамотных спецов в шараге...

Осталось понять две вещи - кто будет писать этот самый ORM

ОРМ писать не надо. Натравил какой-нибудь Entity Framework на базу данных, он сгенерил вам ОРМ. ОРМ пишут в том же Entity Framework в подходе "code first", когда сначала пишешь ОРМ, а по нему генерится база данных. Я пробовал, это какой-то мазохизм. Надо знать кучу нюансов и соглашений, которые всё равно вылетают из головы, если вы эти базы не создаёте на постоянной основе этим code first. И какие-то особенности трахоёбли с миграциями. Т.е. как бы всё можно сделать и даже вроде понятно, если разобраться, но зачем это программисту? БД создаёт и поддерживает DBA, программист натравливает на неё генератор ОРМа, всё. Когда один делаешь какой-то проект, это ещё катит, но обычно сложный проект в одного не делаешь, если не для себя, поэтому опять появляются роли: DBA и далее по списку.

будет анализировать логи (в которых скл-и) в случае ошибки.

Ошибки в простых запросах может сам прогер проанализировать. Там достаточно глянуть, что ты на уровне языка наворотил, не влезая в сгенеренный скуль. Если там что-то навороченное и супероптимизированное - помещается в саму БД в виде хранимки или что там они используют. Тогда ОРМ дёргает хранимку, а ошибки в ней анализирует DBA.

А так да, когда тебя просят проанализировать что-то связанное с БД, можно посидеть и подождать DBA. А можно попытаться разобраться самому.

Зачем делать не свою работу? "К пуговицам претензии есть?" За геройствования зарплату обычно не увеличивают, а нервные клетки, говорят, не восстанавливаются.

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

Для работающего с базой через ОРМ занятие достаточно бесперспективное - генерируемый SQL и ошибка очень малоинформативны в вопросе процессов в базе.

Нда-с. Ты сам-то понял, что сказал?

Смотришь так на генерируемый СКЛ и охреневаешь - а зачем же мне тут 15 join-ов, а? О. А если вот этот вот списочек на ленивую инициализацию переставить, сколько будет? Один? Можно жить. И хлобысь - вместо 10 минут у тебя список задач читается за 100 мс. Никакого высокоумного колдунства, просто посмотрели что же за SQL запрос ORM (тут хибернейт был) генерируется.

А таки сам как?

Написано же - работает ЧЕРЕЗ ОРМ - т.е. пока не указан провайдер то не известно будет ли там вообще хоть какая-то версия СКЛ...

Смотришь так на генерируемый СКЛ и охреневаешь - а зачем же мне тут 15 join-ов, а? О. А если вот этот вот списочек на ленивую инициализацию переставить, сколько будет? Один? Можно жить. И хлобысь - вместо 10 минут у тебя список задач читается за 100 мс. Никакого высокоумного колдунства, просто посмотрели что же за SQL запрос ORM (тут хибернейт был) генерируется.

Тут сразу несколько максим:

1. Я нашёл одну говённую ОРМ (точнее провайдера, но неважно) - значит все ОРМы говно.

2. Если когда-то какая-то ОРМ была говном, то она остаётся говном всегда. Проверять не нужно даже спустя 10 лет.

3. Копаться в полустраничных сложных SQL ручками - высшее благо настоящего программиста!

мотришь так на генерируемый СКЛ и охреневаешь - а зачем же мне тут 15 join-ов, а? О. А если вот этот вот списочек на ленивую инициализацию переставить, сколько будет? Один? Можно жить. И хлобысь - вместо 10 минут у тебя список задач читается за 100 мс.

Я и без просмотра сгенерированного СКЛ вижу, где нужен, а где не нужен lazy loading.

Я и без просмотра сгенерированного СКЛ вижу, где нужен, а где не нужен lazy loading.

Я тобой гожусь! А ошибаешься ты как, в 50% случаев?

Как там ошибиться, когда в entity Framework английским по белому пишешь, что грузить, а что нет?

Шо,ни разу не случалось писать не зная что там будет?

Ни разу. Инфраструктура всегда заренее известна :) (там, где это имеет хоть какой-то смысл)

Может было хотя бы больше одной?

Больше одной БД? Был зоопарк БД от разных вендоров и там не имело значения что за БД "под капотом", т.к. с совтом от этих вендоров я общался через предопределенный интерфейс. Но в таких случаях вообще наплевать есть там БД или нет :)

А компостер там включали?

Нет, его не выключали.

Оставь скрипты и транспорт в покое - первых вообще нет - есть ОРМ, а второе УЖЕ признано рабочим
Но даже если принять его - работа тестера не предполагает фиксинга - только выявление проблем.

Так никто и не говорит, что тестер фиксит.

Тестер выявляет. А что нужно для выявления? - Нужно, чтобы тесты были повторяемыми и независимыми друг от друга. Добиться этого можно только одним способом - создавать новый среду перед каждым исполнением теста и после исполненения все нахрен удалять.

Т.е. перед началом теста БД должна быть девственно чиста и сначала ее заполнить необходимыми для конкретного теста данными. Можно конечно сделать это все в коде, но тут есть несколько минусов: 1) это долго ; 2) нужно читать код чтобы понять начальное состояние БД, т.е. у тебя там будет либо логика (и тогда ты не сможешь сразу однозначно сказать начальное состояние БД), либо будет огромное количество повторений кода (что усложнит сопровождение). Так что инициализировать БД удобнее SQL-скриптом (и поддерживать этот скрипт должен именно тестер).

Им осталось найти того кто сможет ЭТО грамотно описать.

Там все грамотно описано :) Это ты не умеешь читать :) Так что хорошо, что ты им не ответил - меньше работы по отсеву неадекватов :D

английским по белому пишешь, что грузить, а что нет?

Так. А что из этого "нужно" грузить, а что нет? Ты ж хвастался что с одного взгляда сразу распознаешь что "нужно" грузить. Вот перед тобой класс Customer. У него 3 списка: Orders, Addresses и (что б ещё придумать) OpenIssues. Что будем сразу подгружать, а что лениться?

Я с одного взгляда понимать что нужно грузить не умею, завидую.

Написано же - работает ЧЕРЕЗ ОРМ - т.е. пока не указан провайдер то не известно будет ли там вообще хоть какая-то версия СКЛ...

Нда-с. Котик стремительно деградирует. Когда анализируешь ошибки, то слегка понятно какая БД, не?

ПыСы Кстати, вот мы и задели болевую точку всех (ну по крайней мере всех, ихвестных мне) ORM-ов. Пиздя Рекламирующих что, мол, одну строчку в конфиге поменяй и ты уже перелез с DB2 на постгрес. А в реальности в более-менее сложном проекте для каждой базы приходится под неё подгонять запросы. Потому что тут работает лучше с субселектами, а тут с джойнами, а тут планер плохо реагирует если джойним по сложному ключу, а здесь по-разному блокируются таблицы и те де и те пе. Так-то никто не требует знать ни SQL ни мелочи из БД. Но пока ты этого не знаешь, получается хреноватенько. А если у тебя большая нагрузка - забываем сразу про ORM. Ну или идём в облако, скалируем горизонтально (если можем) и открываем пошире кошелёк.

Правильные пацаны добавляют к ленивой подгрузке ещё и виртуализацию (через пейджинг запросов), так что загрузка начинается не только лишь при открытии списка, но и грузится лишь часть списка, видная в текущий момент пользователю, плюс "защитные" диапазоны по краям. А ещё более правильные пацаны не кодят всю эту малину сами, а пользуют готовые фреймворки, т.к. бизнес за изобретение велосипедов не платит.

Т.е. подгружать сразу не будем ничего, а лениться будем везде. Если, конечно, у вас нормальный канал связи, а вы не с марсоходом на Марсе общаетесь. За это заплатим долесекундными задержками при открытии списков и их скролле. Ну или скрывающими эти задержки анимациями, типа "fade in" для постепенно подгружаемых данных. Можно как вариант сразу подгрузить лишь начальное окно с данными на текущую страницу.

Рекламирующих что, мол, одну строчку в конфиге поменяй и ты уже перелез с DB2 на постгрес.

и либку с провайдером

В реальности мало какие проекты меняют СУБД, тем более как перчатки. А те, что меняют, обычно либо спроектированы идиотами, либо находятся в стране идиотов, где вовсю идёт какое-нибудь замещение и надо скакать по СУБДам.

С MVVM и прочими многозвенками тоже кстати что-то подобное. Они были спроектированы типа для частой смены звеньев, но в реальности если вы не идиот, то такой смены либо вообще нет, либо один раз за жизнь проекта, и этот раз можно перетерпеть. Кроме гуя обычно редко что меняется, да и последний лишь по требованию упоротых минетджеров, от безделья придумывающих себе работу, чтобы не уволили.

Потому что тут работает лучше с субселектами, а тут с джойнами, а тут планер плохо реагирует если джойним по сложному ключу, а здесь по-разному блокируются таблицы и те де и те пе. Так-то никто не требует знать ни SQL ни мелочи из БД. Но пока ты этого не знаешь, получается хреноватенько. А если у тебя большая нагрузка - забываем сразу про ORM.

Если у тебя большая нагрузка и куча тонких оптимизаций со всякой куетенью а-ля code to metal, и при этом ты меняешь СУБД как перчатки, то ты идиот. Вы сами ставите противоречащие и взаимоисключающие требования, а виноват у вас ORM. )))

Кстати, если кто забыл, то ORM это в первую очередь объектно-реляционное отображение, а уже потом генерация запросов. Т.е. все критические запросы можно "закодить до металла", а потом дёргать их хранимками из ORM, который будет лишь оборачивать результаты в нужные на уровне приложения сущности.

С MVVM и прочими многозвенками тоже кстати что-то подобное. Они были спроектированы типа для частой смены звеньев

Нет, они были спроектированны не для "частой смены звеньев". Смысл MVVM (других "многозвенок") в том, чтобы 1) разорвать связи между UI и логико ; 2) распараллелить разработку ; 3) улучшить тестируемость