Блог компании OTUS. Онлайн-образование
SQL
Microsoft SQL Server
Интервью
Комментарии 87
+9

Кошмар. Мастерство автомеханика не в том, что он может назвать свойства каждого инструмента в своём наборе, но в том, что он умеет решить задачу, построив в уме оптимальную последовательность шагов, на каждом из которых используется тот или иной инструмент

0
Все верно, в данном посте инструмент SQL, знающий его человек сможет построить такую механику, не знающий — нет. Как определить знающего — задать некоторые вопросы выше.

Вы можете попытаться объяснить, что и под задпчу можнл учить, но практика подсказывает, что задача отдается тем, кто знает, а не тем, кто готов знать (и тратить чужие деньги).

Ну и выше перечисленные знания можно уже причислить к фундаменту, более того — считаю эти вопросы очень поверхностными и знать нужно куда глубже.
+10
Это не вопросы на собеседовании. Это вопросы, которые, по мнению джуниора прочитавшего теорию по SQL, могут задать на собеседовании.
Откуда вообще эти вопросы набрали?
0

Все правильно. Не владея инструментами, человек априори будет не способен решить задачу. А владея — с определенным качеством, зависящим от степени владения. Именно это и нужно проверять — если целью является не проскочить через собес, а найти действительно хорошего специалиста

+11
Объединение — это UNION / UNION ALL,
а JOIN — это соединение.
+6
В SQL есть встроенная функция GetDate ()
Вообще говоря, если в ораклином или микрософьем диалекте SQL это есть, то вовсе не факт, что во всех остальных диалектах это тоже есть. Подобное можно написать и про другие вопросы.
+3
Oracle — sysdate, в PostgreSQL — now(), в MySQL — now(), curdate(), MsSQL — getdate.
А вот ANSI SQL знает вот такое CURRENT_TIMESTAMP. По идее, должна работать везде (проверил на Oracle и PostgreSQL ).
0
Я в MSSQLSERVER только CURRENT_TIMESTAMP и пользуюсь.
Т.к. постоянно забываю, как эта гребаная getdate пишется.
0
Ну вот, даже про транзакцию не спросили… Не говоря уже про WAL и как работает движок базы данных.
Какой смысл этих вопросов, их можно посмотреть в справочнике, а понимание этих механизмов объяснит работу почти любой БД.
+1
Строго говоря WAL никак не связан с SQL. Если покопаться можно найти нежурналируемые реализации РСУБД.
+1
Вопрос 17. Что такое сущности и отношения?
А вспомните-ка для начала, почему реляционные базы называются «реляционными». Что есть relation.

Про НФ тоже странно… Не, неохота дальше комментировать…
+3
Невычитано от слова совсем, даже лень список багов составлять.

P.S. 1) «SQL — ядро реляционной базы данных» — что это было? 2) «Допустимы нулевые значения» (это про unique key) — нулевые это которые? 0 или таки NULL? 3) «Значение NULL представляет значение, которое недоступно, неизвестно, присвоено или неприменимо» — может таки неприсвоено? И не указано, что в т.ч. NULL не равен самому себе.
+1
Спасибо большое, немного не синхронизировались, сейчас постарались подправить все комменты, чтобы было корректнее и понятнее.
+1
А можно уточнить, а по какому SQL стандарту это вопросы? SQL-92 или самому свежему SQL-2016 (который кстати, полностью далеко не все СУБД поддерживают)?
Например, в SQL-92 не нахожу функции GetDate.
+3

16 Денормализация — это всего лишь сознательное нарушение одной из нормальных форм.


Вообще некоторые ответы довольно спорные.

+3
я бы сказал, что больше половины спорные.

Чего стоит одно объяснение ACID — в русской википедии намного корректнее.
+2
Вообще я не увидел ни одного корректного вопроса/ответа. Косяк либо в постановке вопроса, либо в формулировке ответа, либо в нужности самого вопроса (типа NATURAL JOIN, который я, за много лет работы с базой, ни разу не видел и знать не знаю).
+1
А где же ключевой вопрос «икспертов» — чем LEFT JOIN отличается от RIGHT JOIN?
0
Вы можете восстановить данные после удаления

Как это восстановить данные после удаления?
0
1. точно ли имеется ввиду незакомиченые операции?
1.1 точно ли с truncate так же нельзя (в статье указывается truncate как опозит)?
2. вы меня спрашиваете или это ответ на мой вопрос?
3. Я не думаю что автор это имел ввиду )
0
С TRUNCATE точно нельзя. Ну т.е. если эта команда и была вызвана в транзакции, то после отката таблица все равно останется пустой.

UPD:
После операции TRUNCATE для некоторых СУБД (например, Oracle) следует неявная операция COMMIT. Поэтому удаленные в таблице записи нельзя восстановить операцией ROLLBACK. Но существуют и СУБД, в которых операция TRUNCATE может участвовать в транзакциях, например, Microsoft SQL Server.

Короче, не следует полагаться на то, что после отката на некой СУБД данные, удаленные TRUNCATE, вернутся.
0
Вот да, mssql может откатить truncate. Но в любом случае, это странно просто сказать что данные можно восстановить, я ведь могу подумать что и транзакции можно не использовать, мне то всего одну запись удалить надо, а потом восстановить вдруг
+2
Я тоже очень удивился, прочитав слово «восстановление», потом уже дошло, что имелся в виду откат транзакции :) В общем или сам источник кривой, или криво переведено да еще и не вычитано, а скорее всего и то и другое.
+4
Наверное следует поправить следы машинного перевода в вопросе 4, но само по себе это здорово:
SВопросL
+2
Энциклонги приветствуют Вас. Подозреваю, что в оригинале в заголовках вопросов было Q1, Q2, ..., Qx
0
триггеры в MS SQL выполняются либо вместо либо после выполнения инструкции.
и чем отличается count(*) от count(column_name)?
0
А Вы сравните сами, а если вдруг одно поле окажется binary с файлами по несколько мегабайт то сюрприз.
Я вообще всегда использую Count(1)
0
на самом деле есть еще сюрприз
если делать count по конкретному полю то результатом может быть не полное количество строк, а только те где данное поле не null
как тут отработает Count(1) не знаю
+1
Сюрприз?! Серьёзно?
А если подумать — как же может отработать COUNT(1) если нам доподлинно известно что 1 IS NOT NULL? Интрига…
0
На моей тестовой базе в таблице на 10 млн строк, всего 3 числовых поля COUNT(*) — 1,5 сек, COUNT(1) — 0,5 сек.
COUNT(*) именно читает полностью всю строку, а COUNT(1) только заголовки, т.к. не указано поле и ему нечего читать.
0
Уточняющий вопрос: сколько раз вы выполняли эти запросы (по какому количеству исполнений получена статистика)?
0
как тут отработает Count(1) не знаю

в MS SQL Server отпработает без всяких сюрпризов — посчитает все строки. тоже использую COUNT именно так
0

Ну это как бы в стандарте записано, тут скорее возник бы вопрос почему count(*) считает все строки, даже те в которых все значения во всех полях null :)

+1
Если вы работаете с MS SQL, то можете выполнить count(1) и count(*) и посмотреть планы. Сюрприз — они одинаковые, т.е. ваша попытка оптимизации лишняя. ЕМНИП, то ли с 2000-й, то ли с 2005-й версии SQL Server.
0
именно, поэтому если видишь как кто-то использует COUNT(1) можно быть почти уверенным что он пользуется SQL Server с довольно древних версий :)))
-1

Всегда пишу count(1) но никогда не работал с mssql, причина более удобно, плюс нахождение * в запросе, для меня, признак не полной проработки и незавершённости.

+1
count(*) считает все строки, count(column_name) — строки, в которых column_name is not null
+5

Вопросы никак не для собеседования на SQL разработчика.
Для фронтенда, чтоб проверить кругозор. А скорее, умение повторить справочник перед интервью.

+1

То есть 65 — только самые распространенные и это не предел? А чтоб к остальным подготовиться — надо знать назубок ANSI SQL и держать шпаргалку с документацией по постгресу/ораклу/мускулу?

0
Нереляционная система управления базами данных: не существует понятия отношений, кортежей и атрибутов. Пример — Mongo

Причем тут кортежи и атрибуты?

Реляционные базы — это базы, с отношениями между таблицами. Все остальное — может быть реализовано, а может не быть.

Вопросы дублируются (1 и 21)

Язык слишком академический, и неестественный — автор явно сам не слишком хорошо в SQL.

Часто путает сам SQL и его конкретную реализацию в Оракле или MySQL, те же триггеры.

Если планируется еще одна статья — настойчиво рекомендую пригласить нормального ДБА-шника и потратить хотя бы 1-2 вечера на вычитывание. Пусть это будет не 65 а топ-20 вопросов по SQL, зато реально полезных и описанных по-человечески.
+3
пологаю DBA, прочитавшие эту статью, уже пишут свой топ в ответку с со всеми вытекающими )
+1
Реляционные базы прежде всего реализуют реляционную алгебру, в которой множества, кортежи, атрибуты и их отношения. Таблицы это уже абстракция реляционной базы данных и вместо них может быть что-то другое.
0
По-моему определение 1NF совсем неправиельно, ну либо переводчик так криво перевел, что смысл потерялся.
+5
q1 TRUNCATE «Вы не можете восстановить данные»
Если речь идёт об откате транзакции — то это зависит от СУБД. В MS SQL Server можете.

q5 JOIN во всех русскоязычных книгах/материалах (встречавшихся мне) переводится как СОЕДИНЕНИЕ, а не ОБЪЕДИНЕНИЕ.

q10 «Допустимы нулевые значения.» в Unique key — «NULL»евые

q13 «чтение из некластеризованного индекса происходит относительно медленнее» да неужели? А если он покрывающий?

q15 на хабре совсем недавно был материал, почему «диаграммы Венна» плохо подходят для джойнов. Можно было бы и ссылку дать.

q18 «Индексы относятся к методу настройки производительности, позволяющему быстрее извлекать записи из таблицы. Индекс создается для каждого значения и, следовательно, позволяет быстрее получать данные.» если кому-то стало понятно «Что такое индекс» после такого ответа — я ему очень завидую.

q21 «DROP удаляет саму таблицу, и ее нельзя откатить из базы данных» что тут написано? Что нельзя откатить? Таблицу? Дроп? Опять-таки зависит от СУБД. В MS SQL Server можно откатить транзакцию с DROP TABLE.

q23 «Изолированность. Основной целью изолированности является контроль параллелизма.» Классный ответ. Параллелизма чего? Чем традиционное определение не устраивает?

«Долговечность подразумевает, что если транзакция запущена, она будет происходить независимо от того, что может встать у нее на пути, например, потеря питания, сбой или ошибки любого рода.» о, а можно мне хоть в одной СУБД такую «долговечность»? Я такую очень хочу.

Сначала думал, что мои вопросы к первоисточнику, но оказалось, примерно 50/50. Те же свойства ACID в источнике описаны корректно. Самые пуканоразрывающие вопросы (для меня) на совести переводчиков. Какой надмозг перевёл «concurrency control» как «параллелизм», «has been committed» как «была запущена», «NULL values» как «нулевые значения» и «You cannot rollback» как «вы не можете восстановить»?
0
Опять-таки зависит от СУБД. В MS SQL Server можно откатить транзакцию с DROP TABLE.

От СУБД и уровня изоляции. Многие СУБД, которые позволяют DDL откатывать, не позволяют это делать на уровнях изоляции менее строгих, чем Serializable, который используется не сказать чтобы часто.

0
Бэкап — это тоже вариант отката транзакций.
Или GRP в оракле — еще одна помесь бэкапа и транзакций
+1
Бэкап — это тоже вариант отката транзакций.

Нет. Восстановление из бэкапа — это возврат к состоянию БД в некоторый момент времени. В некоторых частных случаях (когда в БД нет и не будет никаких других транзакций кроме вашей) — его можно считать вариантом «отката». Но это именно частный случай.
0
спасибо большое, постарались подправить косяки, так же добавила комменты кое-где по SQL Server.
+1
В вопросе №1 DELETE — DML команда, но в вопросе №2 она уже DDL, как так?
0
Вопрос немного посложнее:

tablename1 имеет 2 поля fieldname1 и fieldname2. Также tablename1 имеет индекс по полю fieldname2.

При выполнении запроса вида:

SELECT fieldname1 FROM tablename1 WHERE fieldname2=1

… имеем Index Scan в плане запроса.

Назовите как MIN 3 причины, почему вместо Index Seek выполняется Index Scan?
0
Эээ…
1. fieldname2 имеет тип varchar, например, и, следовательно, каждое значение в столбце должно быть преобразовано в тип int для сравнения.
2. Индекс по полю имеет низкую селективность, например, 80% значений = 1, и оптимизатор верно оценивает статистику.
3. Значение лежит за пределами статистики по полю, например, вследствие ее устаревания, и оптимизатор неверно оценивает кардинальность.
И потом, индекс скан какого индекса? По полю fieldname2, или скан какого-то другого индекса, кластерного например, или покрывающенго индекса, например вида fieldname1 include (fieldname2)?
Т.е. «почему оптимизатор игнорирует индекс по полю, а использует другой».
Ответ будет: потому, что оптимизатор оценивает издержки на Index seek + key lookup выше, чем скан стороннего индекса, с «добычей» искомого значения из include поля, ну, или из кластерного индекса.

Так пойдет?
0
Я бы добавил
4. Потому что размер индекса меньше некоторого порога (например в две страницы, могут быть различия в реализациях), но индекс при этом покрывающий. Оптимизатор вполне разумно решил что проще будет его просканить :)
0
Да, Вы приняты :)

Вы назвали 3 основных причины: преобразование типов, низкая селективность и проблема со статистикой. Ниже добавили 4-ю…

На счет «индекс скан какого индекса?» — то в примере четко написано, что «tablename1 имеет индекс по полю fieldname2». Все! Не нужно усложнять себе задачу додумывая возможное наличие других индексов или условий…
0
Ненене!
"… имеем Index Scan в плане запроса. "
Не сказано, Scan какого индекса. Т.е. возможен вариант скана в плане, но другого индекса :-)
Так что не «додумывать», а предусматривать варианты.
:-)
0
Хм, когда отключили автообновление индекса и не сделали ребилд после заливки большого куска данных — вроде тоже будет печальный скан?
К тому же, может быть всё уже хорошо, но старый план выполнения вместо поиска всё равно предложит скан.
0
То есть индекс невалидный? Какой смысл, тогда, его сканировать? Его перестраивать надо — в нём же половины данных просто нет!
0
Этот вариант входит в «проблема со статистикой», конкретных причин там может быть много…
0

Кмк, надо отделять мух от котлет.
Т.е. вопросы по SQL для прикладных программистов и вопросы по тюннигу производительности для DBA (в том числе особенности работы индексов).


Ответы на первую часть более менее общие для разных СУБД.


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

+1
Забыли про cross join в списке join, хотя про него многие забывают и если видят — делают огромные глаза и спрашивают «а шо это??»
Типов СУБД гораздо больше — придёт человек и расскажет про k-v хранилища, графо-ориентированную СУБД или объектное хранилище, неудобно же будет.
В том же MSSQL с 2012 появились колоночные индексы, с 2014 — in-memory таблицы.
+2

Правильное название для пункта 15 в его текущей редакции:


"Вопрос 15. Перечислите самые распространенные мифы о типах соединений SQL."

+1

Спасибо за ссылку. Там все изложено верно. Здесь тоже.


К сожалению, подавляющее большинство программистов об этом не знает и свято верит в мифы изложенные в ответе на Вопрос 15.

0
27 вопрос с подвохом. Вот зачем кому-то спрашивать, в чем разница между cross и natural? Почему именно между ними? Суть в том, что если в двух таблицах нет одинаковых столбцов, natural начинает работать как cross. Очевидно, автор видел такой вопрос, знает, как работают обе конструкции, но не понимает, откуда вопрос возник.
0
На практике, на 95% собеседованиях по SQL, в основном, задают практические задачи с различными изощренными применениями joinов.
0
Прямо таки набор заблуждений видимый сквозь призму одной БД.
1) Два вида ББ, как мнение мое и не правильное. А как-же иерархические, сетевые и т.д.?
2) Как писали многие RDBMS умеют откатывать DDL по rollback. Т.е. утверждение не верно.
3) Нету вопроса про DOMAIN
4) Где в foreign key модификаторы on delete set null, on update cascade? Как раз set null разрушение связи.
5) Нормализация БД это приведение к нормальной форме. Всё остальное это следствие нормализации.
6) Первая нормальная форма описана не правильно, смотрите описание в Wiki. В двух словах каждое поле должно содержать одно значение. Т.е. в современных реалиях РСУБД не позволит создать БД которая не удовлетворяет 1НФ.
7) Про индексы написан бред. Насколько упадет производительность БД если в таблице будет много индексов на булевое поле, или на поле константы? Про индексы на несколько полей автор наверное не знает? Что сужествуюn hash, bitmap и т.д. виды индексов?
8) про null надо спрашивать is [not] distinct from и в чер разнца с равенством и неравенством

В итоге эта статья является списком вопросов и вариантами ответов которые показывают вашу некомпетентность.
0
Т.е. в современных реалиях РСУБД не позволит создать БД которая не удовлетворяет 1НФ.

Нормализация относится к схеме, а не данным. Понятие атомарности в терминах НФ зависит от предметной области. Ни кто не помешает разработчику создать текстовое поле, чтобы хранить там имя и фамилию человека. Если с ФИО будут работать как с неделимым значением, тогда выбор корректный для 1НФ. Если предполагаются связи по отдельным словам — тогда нет.
0
По моему это теологический спор.
Посмотрел wiki. Все ссылки на книги изданные после того как мне преподавали нормальные формы. Но они сводятся к тому что один атрибут к одной строке не может содержать два и более значения. К сожалению сейчас не используют термин DOMAIN, с ним некоторые вещи реализуются и объясняются проще.
Если считать что поле содержит два значение разделенных запятой или переводом строки то структуру и записи в БД которые не удовлетворяют первой нормальной формы создать можно.
Если считать что в поле можно запихнуть два INTEGER в виде SET или ARRAY то можно только в некоторых РСУБД.
А если брать БД когда в полях храниться JSON/BSON/XML и т.д. то про какие нормальные формы вообще можно говорить?
Если
0
если брать БД когда в полях храниться JSON/BSON/XML и т.д. то про какие нормальные формы вообще можно говорить?

Ни про какие. Это уже не реляционные данные (точнее таблицы с такими полями не находятся даже в 1НФ если вы хоть как-то на стороне БД используете знание о наличии у них внутренней структуры).
0
Тут лучше начинать вот с этой Википедии en.m.wikipedia.org/wiki/Relational_model.
The relational model's central idea is to describe a database as a collection of predicates over a finite set of predicate variables, describing constraints on the possible values and combinations of values.
.
В реляционной модели данные представляют собой множества предикатов — логических утверждений касательно фактов предметной области, которые можно свести к true или false. Отсюда следует требование атомарности: один факт — одно значение. Если его не выполнить, то в модели проявятся логические противоречия — аномалии. Собственно нормализация это метод последовательной трансформации реляционной модели с целью исключения из нее этих вот самых аномалий.
Домены накладывают дополнительные ограничения на допустимые значения конкретного атрибута. Это могут быть хоть простые типы, например целые числа, хоть даты (из которых за пределами модели можно извлекать компоненты: день, месяц, год и т.п.), хоть массивы, JSON, XML или даже
отдельные отношения. Пока в вашей модели такое значение отражает единичный факт и для связи с другими фактами не требует углубляться во внутреннюю структуру, оно соответствует 1НФ.
+2
Плохой, вредный оригинал, не надо было его переводить, и уж тем более использовать!
В крайнем случае — как список того, как не надо отвечать на вопросы!
Такое ощущение, что автор где-то нагуглил списки вопросов на собеседованиях, а потом нагуглил первые попавшиеся ответы…
+1
Сейчас такой вид постов в англоязычном интернете достаточно распространен. «10 удивительных фактов», «12 топовых вопросов», «5 основных функций». Подавляющее большинство из них откровенный мусор. Наверняка какая-то часть собирается автоматически тупо по набору ключевых слов.
0
Видимо они у себя там так за посещаемость борются. Но здесь-то это зачем?
Только полноправные пользователи могут оставлять комментарии., пожалуйста.