Комментарии 10
Интересно конечно. Но чуток притянуто всё же к "я так вижу, так должны видеть все".
В теме про взаимоблокировки это особенно ярко показано, хоть сам автор и не заметил или заметил это но не понял. А прикол в том, что изначально указано "надо уточнять какие условия для задачи ставятся, какая среда, какая версия SQL, какая СУБД ..." и по факту какие настройки включены на текущем сервере/бд. Примеры автора и его доводы про "ожидаемые ответы" от рекрутёра разбиваются, если этого же автора посадить перед настроенной боевой базой, работавшей, работающей и которая будет ещё работать не один год(т.к система рабочая и никто не даст под эталон перенастраивать) и дать примеры его протестировать, то часть ответов из текста поменяются...
Опять же отчасти автор это говорит местами, но очень очень невнятно и требуя чтобы рекрутер отвечал так как ожидает автор на его "идеальной бд/СУБД".
Может это мой субъективный взгляд работы с реальными проектами под заказчиков, где не получится при всем желании что-то вокруг "северити" накрутить т.к версия СУБД не поднимается выше, т.к операционка не поднимается выше, т.к есть вот это железо и трогать ничего нельзя т.к рядом работает ещё 100500 важных систем. Но.. Не вижу ничего плохого, если рекрутер ничего не скажет про "актуальные/последние" решения из SQL, но хорошо будет понимать основы СУБД. Актуализировать знания - наживное.
Загруженному практикой бывает некогда настолько далеко возвращаться к "базе", к теории. Узнайте, что хотите узнать у кандидата, заходом через решение практических задач.
Золотые слова
должны/могут сработать рефлексы на:
отсутствие
SET NOCOUNT ON
А что в этом плохого? Ну, кроме того, что некоторые библиотеки одной компании не понимают это и кидают ошибку?
отсутствие
RETURNс различающимся значением в случае успеха и неуспеха
Ошибки можно и через механизм raiserror передавать. Бонусом будет возможность вернуть не только код ошибки, но и текстовое сообщение. И ещё по severity их отсортировать. Ну и возможность использовать try/catch для всего, а не городить огород с проверкой части ошибок по кодам возврата.
А ответ на заданный вопрос всё ещё можно найти в самом определении ACID. Транзакции друг от друга изолированы. И в данном конкретном случае мы никакого результата не увидим, пока транзакция с апдейтом не завершится. Наша вторая транзакция будет ожидать возможности навесить Shared-lock и будет ждать, пока оттуда первая не снимет Exclusive-lock.
Как-то странно видеть в статье, которая топит за try/catch и прочие новомодные фишки, полное игнорирование того, что изоляция транзакций может быть реализована разными способами. Snapshot isolation когда появился? В 2012? В 2008?
Команда TRUNCATE в MS SQL Server
Скажите, а сколько раз в production code вам доводилось использовать TRUNCATE? Имеет ли смысл спрашивать про нюансы ее работы, если они нужны раз в три года и их всегда можно подсмотреть в справочнике?
И насколько важны именно аспекты работы TRUNCATE в контексте isolation? Мне кажется куда более полезным на практике, что кандидат представляет, что TRUNCATE в сиквел сервере это DML операция, требующая как минимум прав на ALTER TABLE. И ее нельзя, например, применить к таблице, на которую ссылается внешний ключ. И всяких других граблях, из-за которых использование TRUNCATE может оказаться плохой идеей.
Что получим в результате? Но как же так, ведь мы всё откатили! Опять сломался ACID.
А вот раз тебе и бац - табличные переменные вполне себе имеют некоторые особенности.
ACID относится к сохраняемому состоянию данных СУБД, а значения локальных переменных, даже табличных, в него явно не входят. Никого ведь не удивляет, что при откате транзакции какой-нибудь set @answer = 32 не откатывается.
IMHO, на миддла достаточно будет спросить:
Базовый синтаксис SQL, попросить написать какой-нибудь несложный запрос с рекурсией и оконными функциями
Уровни изоляции, какие бывают и какие эффекты можно наблюдать на каждом уровне
Индексы и стратегии джойнов, их алгоритмическую сложность
Планы запросов, как их курить и что делать, если сиквел сервер выбирает хреновый план.
TRUNCATE в контексте isolation
В контексте durability и в еще более конкретном контексте про "городские легенды" - в тексте заход вроде бы достаточно прозрачный.
И всяких других граблях ... TRUNCATE
значения локальных переменных, даже табличных, в него явно не входят
Это и есть слова, рассуждения, ради которых вбрасываются подобные примеры, задаются такие вопросы. Ровно как рассуждения о том, что в таком-то режиме изоляции будет так-то, а в другом вот так. Это же не тест с бинарным выхлопом: угадал/не угадал.Все примеры или "унаследованы" из реальных собеседований, или сформированы на основе реальных ответов кандидатов с этих собеседований.
Ошибки можно и через механизм raiserror передавать
Это уже почти сформулированная распространённая задачка с собеседований: сколькими способами можно вернуть целочисленное значение из хранимки.
Рандомный код возврата хоть при успехе, хоть при неуспехе - такая же не соблюдённая базовая гигиена, как NOCOUNT и прочие мелочи. На скорость выполнения запросов не влияет, но про отношение к аккуратности, готовность соблюдать соглашения и причесывать старьё немного намекает.
несложный запрос с рекурсией и оконными функциями
такая ветка в описанной схеме собеседования присутствует.
Объясните человеку, который постресом пользуется - а почему ms sql не будет абортить транзакцию, если вставка не отработала из-за foreign key?
Кто может хотеть такого поведения от транзакции?
В тексте есть ответ, и это поведение задокументировано. У ошибок предусмотрен разный уровень серьезности, обычные ошибки к прерыванию пакета команд и откату транзакции не приводят. Если только сам программист не сделал обработку ошибок так, чтобы прерывалось и откатывалось. Такое поведение а) скорее оставлено для обратной совместимости б) позволяет пользоваться сейв-пойнтами и иногда действительно игнорировать ошибки в стиле "а, ну и ладно, потом проапдейчу" в каких-то отдельностоящих сценариях; тот же дэдлок с повтором в цикле.
Для более однозначного поведения придумана опция XACT_ABORT (там в конце страницы как раз пример с ошибками по FK), но она выставлена в OFF по умолчанию - снова из соображений обратной совместимости. И выражение THROW, призванное заменить RAISERROR, по поведению как раз больше похоже на генерацию исключений в других языках: вылетаем либо в CATCH, либо весь батч прерывается, если находимся вне TRY-CATCH. RAISERROR (на котором написано всё легаси) ничего не прерывает, потому приходилось после него писать RETURN. THROW же превращает этот RETURN в unreachable code. Нюансов - толпа. Об том и вопрос.
Все эти собеседования совершенно лишние. Нынешние кандидаты ничего кроме selectinsertupdate не знают, да и те только по верхам. Мне один молодой web программер на моё сообщение что я пишу всю логику своих систем в SP заявил что это антипаттерн, типа почитайте, это во всех книжках пишут, что встроенные процедуры не нужны, достаточно использовать только таблицы. А вот спроси такого простой вопрос, как в одном запросе использовать сортировку по нескольким паоаметрам в ORDER BY, то вряд-ли знает про case. Я бы просто на собеседовании проверял не знания документации по БД, а способность мышления в SQL как в системе не только выборок и вставок, но и в системе обработки данных. Это гораздо важнее чем зубрежка операторов sql.
Автор то выталкивает людей в окно за процедурку из дизайнера, то вспоминает "Как часто приходится обращаться к гуглу и StackOverflow с вопросами уровня "да как оно там пишется?.."
Имхо, людям куда чаще приходится менять, а не создавать, тем более что редактор ошибок не делает.
В принципе, текст полезный. Когда долго не пишешь транзакционный код на т-сиквеле, многие вещи вытесняются (я полез вспоминать scope_identity), но ведь есть MSDN :)
К первому примеру несколько пожеланий:
сократить число таблиц до двух, чтобы показать нарушение внешнего ключа этого достаточно
использовать точку с запятой после каждого оператора
использовать GO для отделения пакетов по созданию таблиц, процедур и собственно кода манипуляции данными, за которым надо бы просто удалять эти таблицы, используя модерновый DROP IF EXISTS
Стартуем без транзакции. Альтернативный вариант вопросов на собеседовании «по SQL»