Comments 24
Ну насчёт табличной функции не совсем точно указано. Если табличная функция возвращает одно поле и одну запись, то её можно использовать и в секции select.
Еще можно добавить, что TRUNCATE (по крайней мере в MySQL) сбрасывает значение AUTO_INCREMENT для первичного ключа таблицы
CTE -- это просто синтаксическая конструкция, будет ли результат подзапроса временно сохраняться в памяти или подзапрос просто распарсится и встроится в общий запрос, зависит от реализации.
В postgre есть даже специальное выражение, указывающее, что CTE должно быть в памяти и не кешироваться на диск.
Я не об этом. Я говорю, что СТЕ-подзапрос вообще не обязан выполняться отдельно, соответственно, нет никаких отдельных результатов, которые надо было бы где-то хранить. По типу как вьюшка, ее текст просто встраивается в общий запрос, так и СТЕ может вести себя аналогичным образом. Взять, к примеру, Оракл. У него есть поведение по умолчанию: если СТЕ в дальнейшем используется всего один раз, парсер поведет себя, как с обычной вьюшкой, а если используется два и более раз, тогда выполнит отдельно и будет использовать полученные результаты. И да, есть хинты MATERIALIZE и INLINE, которыми это поведение по умолчанию можно поменять.
Оператор GROUP BY используется вместе с оператором SELECT и требует, чтобы в операторе SELECT использовалась хотя бы одна агрегатная функция
Нет такого требования, по крайней мере в большинстве основных СУБД.
Что такое self-join и когда используется
Зачем это отдельным пунктом выносить, если там нет никакой доп. семантики? Это обычный джоин, просто таблица джоинится сама с собой.
Не понимаю, зачем про джоины столько всегда текста пишут, если проще одну пикчу приложить.
Ну известно же, что это неправильная картинка. Правильная вот:
А если серьёзно, то эти круги надо рисовать не на множествах A и B, а на декартовом произведении AxB, от чего наглядность несколько улетучивается.
Это неверно просто.
https://habr.com/ru/articles/448072/
https://habr.com/ru/articles/450528/
Честно говоря все фишки нужно представлять. Точное знание на память особо не нужно, так как можно все посмотреть в справочнике по SQL под конкретную СУБД.
Постоянно собеседую кандидатов в команду на системных аналитиков, QA и ETL разработчиков. Так вот, первые 2 вопроса задаю всем и только 70% отвечают верно, некоторые вообще её знаю что это, даже после поправки на primary и foreign key. И отмечу, это позиции мидлов и синьоров ?
Ну я сеньеров на такие вопросы не отвечающих еще не встречал.
Так и тут в тексте описание неверное. Вот посмотрим например википедию:
Неформально выражаясь, внешний ключ представляет собой подмножество атрибутов некоторой переменной отношения R2, значения которых должны совпадать со значениями некоторого потенциального ключа некоторой переменной отношения R1.
Вы тут видите первичный ключ? Я нет. И это правильно. Тут потенциальный ключ во второй таблице. Смотрим что у оракла, к примеру:
[CONSTRAINT [symbol]] FOREIGN KEY
[index_name] (col_name, ...)
REFERENCES tbl_name (col_name,...)
[ON DELETE reference_option]
[ON UPDATE reference_option]
Видите, на что он ссылается? Правильно, на произвольные колонки, а вовсе не на первичный ключ, как написано тут. В общем, это очередная, не единственная ошибка в данном тексте.
Первичный ключ важен, потому что он гарантирует отсутствие дубликатов строк в таблице, а также позволяет эффективно выполнять запросы и индексировать таблицу.
Во-первых, запросы бывают очень разные, в том числе и не по первичному ключу. Во-вторых, и индексы тоже бывают очень разные, разных типов и по любым колонкам, и возможность их создания никак не связана с наличием ключей . Наличие первичного ключа действительно гарантирует что не будет дублей - но точно тоже самое гарантирует unique constraint (которых в таблице может быть много).
Иными словами, практически все что тут написано в абзаце - либо ошибочно, либо неполно.
Первичный ключ важен, потому что он гарантирует отсутствие дубликатов строк в таблице...
Вы ошибаетесь. Это верно не для всех БД. Например в Clickhouse первичный ключ не гарантирует отсутствие дубликатов в любой момент времени.
Приведённый вопросник не указывает однозначно, про какую СУБД идёт речь - отсюда спорность, а местами и ошибочность некоторых утверждений.
Третий вопрос - как раз яркий пример абсолютной СУБД-зависимости. Если для SQL Server ответ подходит, то для MySQL это сплошной пердимонокль, ибо в этой СУБД термины DATABASE и SCHEMA являются синонимами.
В шестом вопросе - очень странно, почему даже не упомянут весьма базовый CROSS JOIN.
В девятом... не скажу за все СУБД, но во многих DELETE и TRUNCATE отличаются механизмом выполнения. DELETE методично удаляет всё указанное по одной записи, что, понятное дело, получается медленным и печальным. А TRUNCATE, не заморачиваясь, удаляет саму таблицу, после чего создаёт её заново, но без записей. Конечно, предварительно проверяется, что это не поломает внешние ссылки, иначе в выполнении будет отказано. А все перечисленные в ответе разницы - всего лишь следствие этой разности механизмов выполнения.
В десятом - не указано, что в некоторых СУБД в запросе каждая временная таблица может использоваться только один раз.
По вопросу 14 - например, в PostgreSQL многие табличные функции, преобразующие CSV/JSON/массивы/прочее в набор записей, прекрасно себе используются в списке вывода, словно они скалярные, а СУБД обеспечивает необходимое "размножение" остальных полей выходного набора.
Ну и вообще от статьи остаётся ощущение тупо передранного чужого конспекта.
Внешний ключ – это столбец или набор столбцов, которые ссылаются на первичный ключ другой таблицы.
Внешний ключ также может ссылаться на столбцы с ограничением уникальности.
Оператор GROUP BY используется вместе с оператором SELECT и требует, чтобы в операторе SELECT использовалась хотя бы одна агрегатная функция
GROUP BY не обязан использовать агрегатные функции. Пусть в этом и мало смысла, но его можно использовать вместо DISTINCT для получения уникальных значений:
SELECT field1
FROM table1
GROUP BY field1
Еще одно различие между DELETE и TRUNCATE заключается в том, что DELETE можно откатить с помощью журнала транзакций, а TRUNCATE – нет
Из-за того, что TRUNCATE не пишет в журнал транзакций, он не может активировать триггеры на удаление, что может стать неприятным сюрпризом.
И ни слова о связываемых переменных (prepared statements).
С терминологией какая то беда у вас, вы элементарные вопросы задаёте так, что опытный разработчик может просто не понять. Например: "такое обобщенное табличное выражение (CTE)" это же просто подзапрос или self-join какой-то придумали. Короче это вопрос не на знания и опыт, а на недавнее прочтение одной книжки с автором вопросов.
Вопросы по SQL, которые часто задают на собеседовании. Часть 1