Что не так с моими ответами по sql и как стоило бы ответить?
Когда искал работу, проходил собеседование на вакансию ASP.NET программист. Срезался на 2 вопросах по MSSQL, Подскажите, как бы вы ответили, мои ответы интервьюеру явно не понравились.
Вопрос 1:
И: Чем отличается хранимые процедуры от хранимых функций?
Я: Да как во многих языках программирования: функция возвращает значение, процедура не возвращает.
И: А что такого можно сделать в хранимой процедуре, чего нельзя сделать в хранимой функции?
Я:. ...
Вопрос 2:
И: Что такое представление?
Я: Выборка на основе некоего запроса, к которой можно обращаться поименно, как и к обычно таблице.
Типа SELECT * FROM ViewName
И: А зачем нужны представления?
Я: Чтобы меньше кода писать, не плодить однотипные запросы. + я не уверен, но возможно, что представления как-то кэшируются и можно получить бонус в производительности.
Оба моих ответа вызвали у интервьюера кислую мину на лице:)))
Ну на первый вопрос я же так до конца ему и не ответил.
Позже погуглил. Есть подозрения, что имелось ввиду, что процедуру можно использовать для возврата табличного значения, но при этом вложив в нее дополнительную логику, помимо основного sql запроса, возвращающего выборку.
Скорее всего на практике ты не сталкивался с тем о чем тебя спрашивали.
В следующий раз, когда споткнешься об подобный вопрос прямо скажи, что не сталкивался с задачей для которой стоит применять Х.
Спроси у интервьювера, где они в проекте сейчас используют данную технологию
mletov это в основном из-за того, что функции предназначены больше для использования в select-ах, а от селектов требуется отсутствие т.н. побочных эффектов
Сергей, спасибо, что-то я сразу и не подумал, хотя и знал
Therapyx, в запросах я бы использовал весьма осторожно. Сильно сложная логика в результате выборки снижает производительность, особенно, если возвращается записей много.
Therapyx: ну мало ли какой проект. Надо смотреть по месту и выбирать что вам более удобно. В программирование нет никаких критериев "как лучше". Есть "как лучше в конкретном случае", потому что плохое но быстрое решение, если оно устраивает по производительности - лучше, чем вылизанное но долгое и дорогое.
Никогда не забывайте, что в своем большинстве, программирование это лишь винтик в бизнесе.
Согласен, что-то слишком круто для ASP.NET программиста. Видимо искали такого дотнетчика, который им если что материализует нужные вьюхи и вернет производительность базы, работающей из последних сил.
Не, ну в самом деле, в больших проектах базой вообще отдельный человек занимается, а там где такого человека нет, делают все через EF с автогенерацией, и не парятся.
Может конечно банк какой-нибудь был, с высокими требованиями в плане общения с БД..
Простой
