Comments 88
Вопросы простые, но нужные. Жду следующей части!
Кошмар. Мастерство автомеханика не в том, что он может назвать свойства каждого инструмента в своём наборе, но в том, что он умеет решить задачу, построив в уме оптимальную последовательность шагов, на каждом из которых используется тот или иной инструмент
Все верно, в данном посте инструмент SQL, знающий его человек сможет построить такую механику, не знающий — нет. Как определить знающего — задать некоторые вопросы выше.
Вы можете попытаться объяснить, что и под задпчу можнл учить, но практика подсказывает, что задача отдается тем, кто знает, а не тем, кто готов знать (и тратить чужие деньги).
Ну и выше перечисленные знания можно уже причислить к фундаменту, более того — считаю эти вопросы очень поверхностными и знать нужно куда глубже.
Вы можете попытаться объяснить, что и под задпчу можнл учить, но практика подсказывает, что задача отдается тем, кто знает, а не тем, кто готов знать (и тратить чужие деньги).
Ну и выше перечисленные знания можно уже причислить к фундаменту, более того — считаю эти вопросы очень поверхностными и знать нужно куда глубже.
UFO just landed and posted this here
Все правильно. Не владея инструментами, человек априори будет не способен решить задачу. А владея — с определенным качеством, зависящим от степени владения. Именно это и нужно проверять — если целью является не проскочить через собес, а найти действительно хорошего специалиста
UFO just landed and posted this here
В SQL не существует VARCHAR2.
UFO just landed and posted this here
Ну вот, даже про транзакцию не спросили… Не говоря уже про WAL и как работает движок базы данных.
Какой смысл этих вопросов, их можно посмотреть в справочнике, а понимание этих механизмов объяснит работу почти любой БД.
Какой смысл этих вопросов, их можно посмотреть в справочнике, а понимание этих механизмов объяснит работу почти любой БД.
UFO just landed and posted this here
«Inner join в MySQL»
А в остальных СУБД?
А в остальных СУБД?
Невычитано от слова совсем, даже лень список багов составлять.
P.S. 1) «SQL — ядро реляционной базы данных» — что это было? 2) «Допустимы нулевые значения» (это про unique key) — нулевые это которые? 0 или таки NULL? 3) «Значение NULL представляет значение, которое недоступно, неизвестно, присвоено или неприменимо» — может таки неприсвоено? И не указано, что в т.ч. NULL не равен самому себе.
P.S. 1) «SQL — ядро реляционной базы данных» — что это было? 2) «Допустимы нулевые значения» (это про unique key) — нулевые это которые? 0 или таки NULL? 3) «Значение NULL представляет значение, которое недоступно, неизвестно, присвоено или неприменимо» — может таки неприсвоено? И не указано, что в т.ч. NULL не равен самому себе.
А можно уточнить, а по какому SQL стандарту это вопросы? SQL-92 или самому свежему SQL-2016 (который кстати, полностью далеко не все СУБД поддерживают)?
Например, в SQL-92 не нахожу функции GetDate.
Например, в SQL-92 не нахожу функции GetDate.
16 Денормализация — это всего лишь сознательное нарушение одной из нормальных форм.
Вообще некоторые ответы довольно спорные.
я бы сказал, что больше половины спорные.
Чего стоит одно объяснение ACID — в русской википедии намного корректнее.
Чего стоит одно объяснение ACID — в русской википедии намного корректнее.
Вообще я не увидел ни одного корректного вопроса/ответа. Косяк либо в постановке вопроса, либо в формулировке ответа, либо в нужности самого вопроса (типа NATURAL JOIN, который я, за много лет работы с базой, ни разу не видел и знать не знаю).
А где же ключевой вопрос «икспертов» — чем LEFT JOIN отличается от RIGHT JOIN?
Вы можете восстановить данные после удаления
Как это восстановить данные после удаления?
REVERT TRANSACTION?
1. точно ли имеется ввиду незакомиченые операции?
1.1 точно ли с truncate так же нельзя (в статье указывается truncate как опозит)?
2. вы меня спрашиваете или это ответ на мой вопрос?
3. Я не думаю что автор это имел ввиду )
1.1 точно ли с truncate так же нельзя (в статье указывается truncate как опозит)?
2. вы меня спрашиваете или это ответ на мой вопрос?
3. Я не думаю что автор это имел ввиду )
С TRUNCATE точно нельзя. Ну т.е. если эта команда и была вызвана в транзакции, то после отката таблица все равно останется пустой.
UPD:
Короче, не следует полагаться на то, что после отката на некой СУБД данные, удаленные TRUNCATE, вернутся.
UPD:
После операции TRUNCATE для некоторых СУБД (например, Oracle) следует неявная операция COMMIT. Поэтому удаленные в таблице записи нельзя восстановить операцией ROLLBACK. Но существуют и СУБД, в которых операция TRUNCATE может участвовать в транзакциях, например, Microsoft SQL Server.
Короче, не следует полагаться на то, что после отката на некой СУБД данные, удаленные TRUNCATE, вернутся.
Наверное следует поправить следы машинного перевода в вопросе 4, но само по себе это здорово:
SВопросL
триггеры в MS SQL выполняются либо вместо либо после выполнения инструкции.
и чем отличается count(*) от count(column_name)?
и чем отличается count(*) от count(column_name)?
А Вы сравните сами, а если вдруг одно поле окажется binary с файлами по несколько мегабайт то сюрприз.
Я вообще всегда использую Count(1)
Я вообще всегда использую Count(1)
на самом деле есть еще сюрприз
если делать count по конкретному полю то результатом может быть не полное количество строк, а только те где данное поле не null
как тут отработает Count(1) не знаю
если делать count по конкретному полю то результатом может быть не полное количество строк, а только те где данное поле не null
как тут отработает Count(1) не знаю
Сюрприз?! Серьёзно?
А если подумать — как же может отработать COUNT(1) если нам доподлинно известно что 1 IS NOT NULL? Интрига…
А если подумать — как же может отработать COUNT(1) если нам доподлинно известно что 1 IS NOT NULL? Интрига…
как тут отработает Count(1) не знаю
в MS SQL Server отпработает без всяких сюрпризов — посчитает все строки. тоже использую COUNT именно так
Ну это как бы в стандарте записано, тут скорее возник бы вопрос почему count(*) считает все строки, даже те в которых все значения во всех полях null :)
Если вы работаете с MS SQL, то можете выполнить count(1) и count(*) и посмотреть планы. Сюрприз — они одинаковые, т.е. ваша попытка оптимизации лишняя. ЕМНИП, то ли с 2000-й, то ли с 2005-й версии SQL Server.
count(*) считает все строки, count(column_name) — строки, в которых column_name is not null
count(column_name) посчитает количество NOT NULL значений в column_name
Вопросы никак не для собеседования на SQL разработчика.
Для фронтенда, чтоб проверить кругозор. А скорее, умение повторить справочник перед интервью.
То есть 65 — только самые распространенные и это не предел? А чтоб к остальным подготовиться — надо знать назубок ANSI SQL и держать шпаргалку с документацией по постгресу/ораклу/мускулу?
Нереляционная система управления базами данных: не существует понятия отношений, кортежей и атрибутов. Пример — Mongo
Причем тут кортежи и атрибуты?
Реляционные базы — это базы, с отношениями между таблицами. Все остальное — может быть реализовано, а может не быть.
Вопросы дублируются (1 и 21)
Язык слишком академический, и неестественный — автор явно сам не слишком хорошо в SQL.
Часто путает сам SQL и его конкретную реализацию в Оракле или MySQL, те же триггеры.
Если планируется еще одна статья — настойчиво рекомендую пригласить нормального ДБА-шника и потратить хотя бы 1-2 вечера на вычитывание. Пусть это будет не 65 а топ-20 вопросов по SQL, зато реально полезных и описанных по-человечески.
По-моему определение 1NF совсем неправиельно, ну либо переводчик так криво перевел, что смысл потерялся.
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» как «вы не можете восстановить»?
Если речь идёт об откате транзакции — то это зависит от СУБД. В 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» как «вы не можете восстановить»?
Опять-таки зависит от СУБД. В MS SQL Server можно откатить транзакцию с DROP TABLE.
От СУБД и уровня изоляции. Многие СУБД, которые позволяют DDL откатывать, не позволяют это делать на уровнях изоляции менее строгих, чем Serializable, который используется не сказать чтобы часто.
спасибо большое, постарались подправить косяки, так же добавила комменты кое-где по SQL Server.
В вопросе №1 DELETE — DML команда, но в вопросе №2 она уже DDL, как так?
Вопрос немного посложнее:
tablename1 имеет 2 поля fieldname1 и fieldname2. Также tablename1 имеет индекс по полю fieldname2.
При выполнении запроса вида:
… имеем Index Scan в плане запроса.
Назовите как MIN 3 причины, почему вместо Index Seek выполняется Index Scan?
tablename1 имеет 2 поля fieldname1 и fieldname2. Также tablename1 имеет индекс по полю fieldname2.
При выполнении запроса вида:
SELECT fieldname1 FROM tablename1 WHERE fieldname2=1… имеем Index Scan в плане запроса.
Назовите как MIN 3 причины, почему вместо Index Seek выполняется Index Scan?
Эээ…
1. fieldname2 имеет тип varchar, например, и, следовательно, каждое значение в столбце должно быть преобразовано в тип int для сравнения.
2. Индекс по полю имеет низкую селективность, например, 80% значений = 1, и оптимизатор верно оценивает статистику.
3. Значение лежит за пределами статистики по полю, например, вследствие ее устаревания, и оптимизатор неверно оценивает кардинальность.
И потом, индекс скан какого индекса? По полю fieldname2, или скан какого-то другого индекса, кластерного например, или покрывающенго индекса, например вида fieldname1 include (fieldname2)?
Т.е. «почему оптимизатор игнорирует индекс по полю, а использует другой».
Ответ будет: потому, что оптимизатор оценивает издержки на Index seek + key lookup выше, чем скан стороннего индекса, с «добычей» искомого значения из include поля, ну, или из кластерного индекса.
Так пойдет?
1. fieldname2 имеет тип varchar, например, и, следовательно, каждое значение в столбце должно быть преобразовано в тип int для сравнения.
2. Индекс по полю имеет низкую селективность, например, 80% значений = 1, и оптимизатор верно оценивает статистику.
3. Значение лежит за пределами статистики по полю, например, вследствие ее устаревания, и оптимизатор неверно оценивает кардинальность.
И потом, индекс скан какого индекса? По полю fieldname2, или скан какого-то другого индекса, кластерного например, или покрывающенго индекса, например вида fieldname1 include (fieldname2)?
Т.е. «почему оптимизатор игнорирует индекс по полю, а использует другой».
Ответ будет: потому, что оптимизатор оценивает издержки на Index seek + key lookup выше, чем скан стороннего индекса, с «добычей» искомого значения из include поля, ну, или из кластерного индекса.
Так пойдет?
Я бы добавил
4. Потому что размер индекса меньше некоторого порога (например в две страницы, могут быть различия в реализациях), но индекс при этом покрывающий. Оптимизатор вполне разумно решил что проще будет его просканить :)
4. Потому что размер индекса меньше некоторого порога (например в две страницы, могут быть различия в реализациях), но индекс при этом покрывающий. Оптимизатор вполне разумно решил что проще будет его просканить :)
Да, Вы приняты :)
Вы назвали 3 основных причины: преобразование типов, низкая селективность и проблема со статистикой. Ниже добавили 4-ю…
На счет «индекс скан какого индекса?» — то в примере четко написано, что «tablename1 имеет индекс по полю fieldname2». Все! Не нужно усложнять себе задачу додумывая возможное наличие других индексов или условий…
Вы назвали 3 основных причины: преобразование типов, низкая селективность и проблема со статистикой. Ниже добавили 4-ю…
На счет «индекс скан какого индекса?» — то в примере четко написано, что «tablename1 имеет индекс по полю fieldname2». Все! Не нужно усложнять себе задачу додумывая возможное наличие других индексов или условий…
Ненене!
"… имеем Index Scan в плане запроса. "
Не сказано, Scan какого индекса. Т.е. возможен вариант скана в плане, но другого индекса :-)
Так что не «додумывать», а предусматривать варианты.
:-)
"… имеем Index Scan в плане запроса. "
Не сказано, Scan какого индекса. Т.е. возможен вариант скана в плане, но другого индекса :-)
Так что не «додумывать», а предусматривать варианты.
:-)
Хм, когда отключили автообновление индекса и не сделали ребилд после заливки большого куска данных — вроде тоже будет печальный скан?
К тому же, может быть всё уже хорошо, но старый план выполнения вместо поиска всё равно предложит скан.
К тому же, может быть всё уже хорошо, но старый план выполнения вместо поиска всё равно предложит скан.
Кмк, надо отделять мух от котлет.
Т.е. вопросы по SQL для прикладных программистов и вопросы по тюннигу производительности для DBA (в том числе особенности работы индексов).
Ответы на первую часть более менее общие для разных СУБД.
Ответы на вторую сильно завязаны на особенности движка конкретной СУБД. Более того, могут отличаться, в зависимости от версии движка.
Забыли про cross join в списке join, хотя про него многие забывают и если видят — делают огромные глаза и спрашивают «а шо это??»
Типов СУБД гораздо больше — придёт человек и расскажет про k-v хранилища, графо-ориентированную СУБД или объектное хранилище, неудобно же будет.
В том же MSSQL с 2012 появились колоночные индексы, с 2014 — in-memory таблицы.
Типов СУБД гораздо больше — придёт человек и расскажет про k-v хранилища, графо-ориентированную СУБД или объектное хранилище, неудобно же будет.
В том же MSSQL с 2012 появились колоночные индексы, с 2014 — in-memory таблицы.
Правильное название для пункта 15 в его текущей редакции:
"Вопрос 15. Перечислите самые распространенные мифы о типах соединений SQL."
27 вопрос с подвохом. Вот зачем кому-то спрашивать, в чем разница между cross и natural? Почему именно между ними? Суть в том, что если в двух таблицах нет одинаковых столбцов, natural начинает работать как cross. Очевидно, автор видел такой вопрос, знает, как работают обе конструкции, но не понимает, откуда вопрос возник.
Natural join — это, разве, не типичная оракуловская фишка?
ИМХО natural join это плохая практика, ещё хуже чем select *
Вроде как нет. На практике ни разу не встречал, если честно.
На практике, на 95% собеседованиях по SQL, в основном, задают практические задачи с различными изощренными применениями joinов.
Прямо таки набор заблуждений видимый сквозь призму одной БД.
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 и в чер разнца с равенством и неравенством
В итоге эта статья является списком вопросов и вариантами ответов которые показывают вашу некомпетентность.
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 и в чер разнца с равенством и неравенством
В итоге эта статья является списком вопросов и вариантами ответов которые показывают вашу некомпетентность.
Т.е. в современных реалиях РСУБД не позволит создать БД которая не удовлетворяет 1НФ.
Нормализация относится к схеме, а не данным. Понятие атомарности в терминах НФ зависит от предметной области. Ни кто не помешает разработчику создать текстовое поле, чтобы хранить там имя и фамилию человека. Если с ФИО будут работать как с неделимым значением, тогда выбор корректный для 1НФ. Если предполагаются связи по отдельным словам — тогда нет.
По моему это теологический спор.
Посмотрел wiki. Все ссылки на книги изданные после того как мне преподавали нормальные формы. Но они сводятся к тому что один атрибут к одной строке не может содержать два и более значения. К сожалению сейчас не используют термин DOMAIN, с ним некоторые вещи реализуются и объясняются проще.
Если считать что поле содержит два значение разделенных запятой или переводом строки то структуру и записи в БД которые не удовлетворяют первой нормальной формы создать можно.
Если считать что в поле можно запихнуть два INTEGER в виде SET или ARRAY то можно только в некоторых РСУБД.
А если брать БД когда в полях храниться JSON/BSON/XML и т.д. то про какие нормальные формы вообще можно говорить?
Если
Посмотрел wiki. Все ссылки на книги изданные после того как мне преподавали нормальные формы. Но они сводятся к тому что один атрибут к одной строке не может содержать два и более значения. К сожалению сейчас не используют термин DOMAIN, с ним некоторые вещи реализуются и объясняются проще.
Если считать что поле содержит два значение разделенных запятой или переводом строки то структуру и записи в БД которые не удовлетворяют первой нормальной формы создать можно.
Если считать что в поле можно запихнуть два INTEGER в виде SET или ARRAY то можно только в некоторых РСУБД.
А если брать БД когда в полях храниться JSON/BSON/XML и т.д. то про какие нормальные формы вообще можно говорить?
Если
если брать БД когда в полях храниться JSON/BSON/XML и т.д. то про какие нормальные формы вообще можно говорить?
Ни про какие. Это уже не реляционные данные (точнее таблицы с такими полями не находятся даже в 1НФ если вы хоть как-то на стороне БД используете знание о наличии у них внутренней структуры).
Тут лучше начинать вот с этой Википедии en.m.wikipedia.org/wiki/Relational_model.
В реляционной модели данные представляют собой множества предикатов — логических утверждений касательно фактов предметной области, которые можно свести к true или false. Отсюда следует требование атомарности: один факт — одно значение. Если его не выполнить, то в модели проявятся логические противоречия — аномалии. Собственно нормализация это метод последовательной трансформации реляционной модели с целью исключения из нее этих вот самых аномалий.
Домены накладывают дополнительные ограничения на допустимые значения конкретного атрибута. Это могут быть хоть простые типы, например целые числа, хоть даты (из которых за пределами модели можно извлекать компоненты: день, месяц, год и т.п.), хоть массивы, JSON, XML или даже
отдельные отношения. Пока в вашей модели такое значение отражает единичный факт и для связи с другими фактами не требует углубляться во внутреннюю структуру, оно соответствует 1НФ.
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НФ.
Плохой, вредный оригинал, не надо было его переводить, и уж тем более использовать!
В крайнем случае — как список того, как не надо отвечать на вопросы!
Такое ощущение, что автор где-то нагуглил списки вопросов на собеседованиях, а потом нагуглил первые попавшиеся ответы…
В крайнем случае — как список того, как не надо отвечать на вопросы!
Такое ощущение, что автор где-то нагуглил списки вопросов на собеседованиях, а потом нагуглил первые попавшиеся ответы…
Вопрос 11. Что такое внешний ключ (Foreign key)?
Внешний ключ поддерживает ссылочную целостность, обеспечивая связь между данными в двух таблицах.
Внешний ключ в дочерней таблице ссылается на первичный ключ в родительской таблице.
Ответ не полный... Внешний ключ может ссылаться не только на primary key, но и на unique.
Вопрос 19. Опишите различные типы индексов.
Есть три типа индексов, а именно:
Уникальный индекс (Unique Index): этот индекс не позволяет полю иметь повторяющиеся значения, если столбец индексируется уникально. Если первичный ключ определен, уникальный индекс может быть применен автоматически.
Кластеризованный индекс (Clustered Index): этот индекс меняет физический порядок таблицы и выполняет поиск на основе значений ключа. Каждая таблица может иметь только один кластеризованный индекс.
Некластеризованный индекс (Non-Clustered Index): не изменяет физический порядок таблицы и поддерживает логический порядок данных. Каждая таблица может иметь много некластеризованных индексов.
Бгг... можно ответить в таком же духе - есть 3 типа - красный, круглый, теплый )))))))))))))
Я понял, это вопросы для тех кто только что закончил курсы, причем если ответить на них правильно но не так как в курсе - для собеседующего будешь незнайкой )))))))))))))))))))
Sign up to leave a comment.
Топ-65 вопросов по SQL с собеседований, к которым вы должны подготовиться в 2019 году. Часть I