Вопросы и задачи по SQL на собеседованиях 2024: готовьтесь эффективно

[kalapanga]

Автор, Вы реально считаете, что в первом задании правильный ответ 12 и 10 строк?

[Marina_Chernysheva]

Спасибо, вы абсолютно правы, была опечатка, скопировала ответ из другого примера аналогичной задачи. Уже исправила

[kalapanga]

Исправили - хорошо! Надеюсь и остальные примеры перепроверили (их я не проверял).

[zodchiy]

Блокировки, транзакции, изолированность, кластерный/некластерный индексы, типы ключей и их плюсы и минусы, подзапросы, оконные функции, index seek/index scan/trable scan, нормализация.

[santjagocorkez]

1. Почти все ответы по join неправильные, ответы даны для специальных случаев outer join, тогда как в левой части определения конструкция указана без квалификатора, что по умолчанию означает inner

2. Primary key — это не поле и не набор полей, это ограничение таблицы (constraint)

3. Truncate, по крайней мере, в PostgreSQL, транзакционный, как и большая часть DDL (хоть и, к сожалею, не вся). Поправка: транзакционность здесь распространяется только на возможность отката изменений, а вот отсутствие данных параллельные транзакции будут наблюдать сразу, по крайней мере, до отката транзакции

Что-то утомительно стало почти в каждом ответе видеть ошибку, причём, грубую.

PS: duckdb — это какое-то лютое поделие, которое, судя по документации, сваяли ради нового ключевого слова, при том, что в SQLite3 проблема решается стандартным синтаксисом, хоть и, конечно, в большее количество слов. А чтобы пользователи не роптали, прикрутили в драйвер зависимость от пандас и простенькое апи, чтобы туда выплевывать результат. Забыв про этом умолчать, что импорт пандас занимает дикое количество времени, в лямбдах Амазона, например, насколько секунд.

[sshikov]

1. Primary key — это не поле и не набор полей, это ограничение таблицы (constraint)

И еще их может быть несколько (unique). И еще оно может быть выключено. Из чего автоматически следует, что значения в колонках не будут уникальными, и потом при включении constraint произойдет что-либо типа валидации.

[Akina]

Задание 3 - вот хотелось бы у автора узнать, как абсолютно один и тот же код может быть решением для двух в принципе разных вопросов?

Задание 3 вопрос 2 - ответ на вопрос обязан предусмотреть, что два и более промокодов могут иметь одинаковое количество. WITH TIES либо его эмуляция.

Задание 4 - ответ неверный. В условии указано, что поле id является первичным ключом. Следовательно, выходной набор будет иметь строго 10 записей, никакого дублирования по b.id, который по условию есть первичный ключ, быть не может в принципе.

Задание 5 - оба ответа неверны. Первый - в зависимости от collation, второй - всегда.

Вопрос 1 - ответ неверный. Есть ещё LATERAL JOIN, в различных вариациях.

Вопрос 2 - значение первичного ключа не "должно быть уникальным", а "уникально в пределах имеющихся данных". Либо данные разрушены.

Вопрос 3 - ничто не мешает использовать HAVING для фильтрации неагрегированных данных. Более того, в некоторых (достаточно редких на практике) условиях это необходимо делать, чтобы получить возможность использовать имеющийся композитный индекс.

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

Ну и хотелось бы понять, каким боком этот опус прислонился к хабу Recovery Mode.

Да, и плюс написанное ранее, само собой.

[Batalmv]

SELECT name FROM table WHERE name LIKE "A%";

или

SELECT name FROM table WHERE LOWER(name) LIKE "a%";

Я бы вот тут засомневался, так ли уж правильно приводить второй запрос, разве чтобы потом порассуждать почему это не лучшая идея

А вообще вопросы примитивные, разве что для QA подходят, или студентов

[ptr128]

Зачем кувыркаться через ROW_NUMBER(), если есть DISTINCT ON?

[Akina]

В случае Постгресса - да. Но кто ещё это понимает?

[ptr128]

Явно указанный в задаче DuckDB.

[titan_pc]

"Сколько строк выведет программа?" Вопросы как будто для школьников... Чат джпт план собеса составлял 100%

[Mih_dim]

В 4 задании в ответе ошибка: если в А pk , а в Б fk то записей будет от 10 до 109. 109 будет тогда когда один id из а, будет повторяться в Б 100 раз.

[ferrablack]

Статья ради галочки, видимо. Куча ошибок в приведённых примерах, опять попытка принести теорию в дцатый раз (зачем?!). Неужели определения джойнов это такая труднодоступная информация, что её в каждую статью про собесы sql засовывают?

[anokru]

right join придумали геи, для заданий на собеседовании.

[Akina]

Ну это ты зря... далеко не каждый пи**рас - гей.