Как стать автором
Обновить

Комментарии 22

Молодец. На этом ресурсе очень не хватает подобных обзоров-хаутушек.
Заплюсовал бы, еслиб администрация не снесла мне карму и силу за коммент про нашу власть :)
Очень удобная штука, при определенной сноровке.
Хорошая статья. В очередной раз убедилась что если работал с MS SQL Server, то и в MySQL разберешься без труда)
НЛО прилетело и опубликовало эту надпись здесь
Если работал реляционной базой данных, то в любой другой реляционной базе данных разберешься без труда
Не хватает только одного — понимания будут ли запросы использующие view использовать индексы. И насколько правильно они их будут использовать.
Зависит от запроса. Если используется алгоритм MERGE, то будут. Сравните explain итогового запроса через таблицу и запроса через представление, увидите их полную идентичность.
Подлые тролли сожрали мою карму! Горе мне, говночитателю, не могу плюс накликать я, о мастер!
Если только читаешь — нафиг карма? :) А я за тебя уже плюсанул
Довольно интересно, только хотелось бы узнать — где может реально пригодиться на практике этот функционал? Я просто может с утра не проснулся, кто-нибудь поделится?

ЗЫ плюсанул бы, расписано очень качественно, да нечем *PARDON*
Если Вы не знаете где, то значит оно вам и не надо.
Во-первых, для настройки прав доступа. Помню во времена MySQL 4 испытывал трудности с тем, чтобы дать пользователям права на отдельные строки таблицы.

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