Молодец. На этом ресурсе очень не хватает подобных обзоров-хаутушек.
Заплюсовал бы, еслиб администрация не снесла мне карму и силу за коммент про нашу власть :)
Зависит от запроса. Если используется алгоритм MERGE, то будут. Сравните explain итогового запроса через таблицу и запроса через представление, увидите их полную идентичность.
Довольно интересно, только хотелось бы узнать — где может реально пригодиться на практике этот функционал? Я просто может с утра не проснулся, кто-нибудь поделится?
ЗЫ плюсанул бы, расписано очень качественно, да нечем *PARDON*
Очень удобно использовать вьюшки для создания виртуальных таблиц. Например, какому-то приложению требуется поле из этой таблицы, пару полей из той, еще парочка из третьей и т.д. Запрос получается трехэтажный. Вот чтобы этот запрос не таскать по всему приложению, его проще записать во вьюшку, а в приложении выбирать все поля из этой вьюшки. Просто и удобно! Программист приложения может даже и не подозревать что он выбирает данные из вьюшки, а не из реальной таблицы. Получается нечто вроде инкапсуляции по ООП.
Главное, делая представления, четко осознавать что творишь, чтобы не налепить монстрообразных соединений на джоинах без индексов. А то view будет потом ползать еле-еле
Очень полезная статья. Почему-то раньше думал, что вьюшки обновляются только при изменении связанных с ними таблиц, а по запросам пользователей отдают кэш… Плюсанул все, что можно, пойду еще сайт поизучаю :)
Следует, однако, помнить, что VIEW работает медленней, чем прямой запрос. Не знаю, насколько это универсально; я тестировал на нескольких тысячах записей с тремя LEFT JOIN. VIEW работал на несколько процентов медленней. Поэтому рекомендую сравнивать скорость выполнения в каждом потенциально критическом случае.
Респект автору за статью. Лет 7 назад на оракле писал, пользовал тригеры, еще что-то… забыл уже. И не думал, что в мускле есть вьюшки. Спасибо, открыл глаза :) теперь пользовать буду.
Представления (VIEW) в MySQL