Как сейчас с работой'24?
3. Спецсимволы и экранирование Oracle: Для экранирования специальных символов (например, %, _) используется ключевое слово ESCAPE. Пример: sql SELECT * FROM table_name WHERE column_name LIKE '50\%' ESCAPE '\'; Это позволит найти строки, содержащие 50%. MS SQL Server: Аналогично, но символ экранирования должен быть указан явно. Пример: sql SELECT * FROM table_name WHERE column_name LIKE '50!%' ESCAPE '!';
Код один и тот же, но ваш ИИ пишет так, будто тут противопоставление.
Зачем мне это знать? :)
Если писать запросы для оракла, то единожды нагуглив особенности, будешь их знать и использовать.
Где-то наверное нужно использовать в работе и МС и оракл, но это все-таки исключение. Обычно используется только одна БД.
камон, выше ты писал, что нет смысла требовать опыт работы в определенной СУБД
я тебе привел пример, где ты с опытом в MS SQL выстрелишь себе в ногу, продолжая использовать привычный тебе синтаксис в оракле.
и не надо тут про гугл, даже последний душнила не гуглит знакомые ему функции
где ты с опытом в MS SQL выстрелишь себе в ногу, продолжая использовать привычный тебе синтаксис в оракле.
Да не особенно и выстрелишь себе в ногу :) Существенная разница только в чувствительности к регистру.
Эти проблемы выявятся довольно быстро.
Вы не возьмёте спеца по Ораклу в МС Скуль или наоборот лишь потому, что он не знает особенности другой СУБД, о которых вы можете его предупредить и которые он может быстро изучить? Это как те ашарки, которые без точного совпадения буковок в резюме отвергают спецов с опытом, но приглашают массово малоопытных, но с буковками в нужном порядке?
Он наверное хочет вообще без проблем - только пришёл и сразу начал таски закрывать в темпе. ))
Вообще, судя по вою работодателей, вроде как проблема просто нормального вменяемого разраба найти. Которому сменить СУБД не такая уж проблема, т.к. они отличаются меньше, чем даже родственные языки программирования (типа Джавы и Сишарпа), если речь не идёт о супероптимизациях на базе глубокого понимания самых тонких кишок этих СУБД. А тут до сих пор идёт битва за нужный порядок и точное совпадение буковок в резюме. Это даже не "требуются многоопытные малооплачиваемые", это в другой плоскости - психической.
и не надо тут про гугл, даже последний душнила не гуглит знакомые ему функции
Ну не погуглил первый раз, второй. Вылезли ошибки, не прошли тесты. Дальше погуглил и поправил. Проблемы?
Но на собесе да - не ответил на каверзный вопрос "в чём сходства и различия оператора like в разных СУБД".
я же написал зачем
------
не-а... ты написал - что - а - зачем - это не с их стороны.
очень условная вещь
-----
это - да.я даже пойму - начало по нахождению исполнителя.
Только вот перед тем как апплаится на не постоянную работу
мне нужно оценить насколько предлагаемая интенсивность
совпадает с моими возможностями. но почему-то всегда
предполагается что данная оценка за пределами моих возможностей,
хотя и входит в перечень служебных обязанностей.
Так может быть эта разница и не нужна?
-----
А тогда зачем вообще об SQL вспоминать?
Элементарно же - меньше требований = ниже оплата.
вполне адекватные требования
------
Хотелось бы обоснования.
Дело в том, что Я не умею работать из JS с MSSQL'19. И не нашел описания как это возможно.
не пояснишь КАК это делается?
и не надо тут про гугл, даже последний душнила не гуглит знакомые ему функцииНу не погуглил первый раз, второй. Вылезли ошибки, не прошли тесты. Дальше погуглил и поправил.
Кстати такие же мысли пришли когда читал это днём, для этого и проводят тесты и отлавливают баги, до полного удовлетворения заказчика!

Только вот перед тем как апплаится на не постоянную работу
мне нужно оценить насколько предлагаемая интенсивность
совпадает с моими возможностями. но почему-то всегда
предполагается что данная оценка за пределами моих возможностей,
хотя и входит в перечень служебных обязанностей.
Если не кинут с первой зарплатой, уже норм. Дальше пусть сами решают, нужны вы им и ваш темп работы или нет.
Хотелось бы обоснования.
Дело в том, что Я не умею работать из JS с MSSQL'19. И не нашел описания как это возможно.
Пройдёте первый тупняк на собесе, доберётесь до непосредственной работы и коллег, там вам скажут, что на самом деле нужно делать. Сейчас только так принимают. ))
Только вот перед тем как апплаится на не постоянную работу мне нужно оценить насколько предлагаемая интенсивность совпадает с моими возможностями. но почему-то всегда предполагается что данная оценка за пределами моих возможностей,
Ты бредишь :) Если что-то не написано, значит этот фактор нерелевантентен. Перевожу на русский - им важно найти человека и дата старта не так уж и важна, т.е. они готовы начать уже завтра, но вместе с тем могут и подождать 1-2-3 месяца. Короче говоря, старт и продолжительность - это вещи о которых можно разговаривать.
Если у тебя не хватает опыта и/или гибкости понять это, то нафиг ты им такой не нужен :)
А тогда зачем вообще об SQL вспоминать?
Потому что SQL нужен :) Им не релевантны особенности
имплементаций от разных фирм. Но при этом опыт написания SQL запросов им нужен.
Хотелось бы обоснования.Дело в том, что Я не умею работать из JS с MSSQL'19. И не нашел описания как это возможно.не пояснишь КАК это делается?
Конечно объясню :) Читаем то, что ты выложил:
Как видишь, тут нет ни слова о том, что надо будет работать с MSSQL'19 из JS. Однако говорится, о том, что разработка на C# с использованием .Net. Более того, тут сказано про MVC, т.е. это скорее всего проект с веб мордой, т.е. умение работать с JS тоже обосновано (хотя про JS ты в своей выжимки ничего и не писал).
К сожалению, ты напрочь не умеешь читать объявления с предполагаемыми
проектами :) Я вообще удивляюсь, как ты находишь работу :D
Я вообще не знаю толком СУБДы и SQL, кроме простейших вещей. Каждый раз, когда надо что-то не очень тривиальное, приходится рыться в поиске или, как щас новомодно, спрашивать ИИ. Все запросы делаю через ORM. А для ORM пофиг, какая СУБД - был бы подходящий провайдер.
Для БД отдельный DBA нужен, кроме случаев опять же простейших баз данных. Вешать эту задачу на программиста, даже фуллстека - глупость.
это вещи о которых можно разговаривать.
------
где-то в глубине архивов есть мое описание требований к секретарю.
там тоже можно много об чем разговаривать, но опыт управления удаленными серверами находящимися в оффе - обязателен.
Если что-то не написано, значит этот фактор нерелевантентен.
-----
Угу...
Как то давно делали оценку работы программистов.
Наиболее близким по выполняемым действиям была принята работа машинистки в машинописном бюро.
Хорошая машинистка, а нанимать предполагалось только превосходных программистов, должна печатать на уровне чемпионки - 120 символов в минуту.
Дальше пояснять про нерелевантность фактора или уже понятно?
опыт написания SQL запросов им нужен.
-----
Ну у меня тут же возникает вопрос - Зачем миддле-тестеру, т.е. челу который не будет общаться даже с кодописателем не знающим с какой именно базой он работает, знания SQL неопределенной базы? Для написания и выполнения тестов это не нужно. Фикинг выявляемых багов - вне компетенции.
тут нет ни слова о
-----
ну об этом чутка выше.
Да. смешал.
бо, оба из категории не заинтересовавших и потому неразличимых.
Вешать эту задачу на программиста, даже фуллстека - глупость.
Осталось понять две вещи - кто будет писать этот самый ORM и кто будет анализировать логи (в которых скл-и) в случае ошибки.
А так да, когда тебя просят проанализировать что-то связанное с БД, можно посидеть и подождать DBA. А можно попытаться разобраться самому.
где-то в глубине архивов есть мое описание требований к секретарю.
там тоже можно много об чем разговаривать, но опыт управления удаленными серверами находящимися в оффе - обязателен.
Без понятия о чем ты говоришь :)
Как то давно делали оценку работы программистов.
Наиболее близким по выполняемым действиям была принята работа машинистки в машинописном бюро.
Ну значит либо так делали оценку, либо (скорее всего) ты как-то не так понял :D Тем более, что с пониманием написанно у тебя есть явные проблемы ;)
Дальше пояснять про нерелевантность фактора или уже понятно?
понятно только одно - ты как всегда генерируешь бред :) Ктоме этого ничего не понятно.
Зачем миддле-тестеру, т.е. челу который не будет общаться даже с кодописателем не знающим с какой именно базой он работает, знания SQL неопределенной базы?
Ну вот опять. Делаешь выводы опираясь не известно на что. Потом опираять на собственные выводы строить какие-то левые предположения :) И при этом почему-то удивляешься полученному результату.
1) Никто не говорил, что "кодописатель" не знает с какой базой он работает. "Кодописатель" знает.
2) Никто не говорил, что тестер не знает с какой базой он работает. Тестер знает.
3) Зачем тестеру может быть полезно знание SQL я уже говорил. Но чукча же не читатель, чукча писатель. Пишу последник раз: тесру может быть необходимо исполнять уже написанные кем-то SQL-запросы. Кроме того, ему может быть необходимо вносить какие-то минимальные изменения в существующие запросы.
Для написания и выполнения тестов это не нужно.
Может быть нужно. Зависит от того что и как тестируется.
ну об этом чутка выше.
Да. смешал.
бо, оба из категории не заинтересовавших и потому неразличимых.
Чутка выше все тоже самое:
У тебя слишком уж очевидные проблемы с пониманием написанных текстов. В этом объявлении речь также идет о разработке чего-то там с вэб-мордой. Очевидно, что JS нужен для web-морды, а MSSQL'2019 для бэкенда, который работает на .Net.
Должен сказать, на этих двух примерах отчетливо видно, что долбаеб тут ты, а не рекрутеры.