Здравствуйте, Blackie!

Здесь всё зависит от задач, которые стоят перед Вами. Представление может не только собрать данные из нескольких таблиц, оно может так же провести некоторую фильтрацию, разграничить доступ к данным в зависимости от пользователя. В крупных проектах часто раграничивают права пользователей: данные даже одной таблицы могут быть полностью доступны только администратору, в то время как некоторая выборка из них - операторам (для каждого - своя). Можно наложить полный запрет на доступ к базовой таблице для операторов, одновременно сделать несколько представлений, каждое из которые фильтрует данные по некоторому правилу, и каждому оператору разрешить доступ к тому или иному представлению.
Третье важное применение представления - защита клиентского приложения от изменяющейся структуры базы данных. Поясню: требования к проекту могут измениться уже после того, как он окажется в процессе активной разработки. Например, какое-то из полей может вдруг стать вычисляемым или просто "переехать" в другую таблицу. Если чтение организовано через представления, а запись - через хранмые процедуры, то уже готовый код может и не заметить изменений в структуре, а это порой может сэкономить несколько месяцев работы целой группе программистов.

Повторюсь: внимательно посмотрите на задачу, стоящую перед Вами, и после этого Вы сможете решить, насколько эффективно будет использование такого посредника, как представление. Я же хочу упомянуть ещё об одном свойстве таких объектов: как правило, представление данных лежит внутри сервера СУБД в откомпилированном виде, поэтому если оно сложным образом собирает данные из нескольких таблиц, доступ к этим данным через него будет более быстрым, чем при использовании прямого SQL-запроса.