Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > СУБД, общие вопросы > Когда следует использовать представления?

Автор: Bikutoru 9.4.2006, 12:28

Здраствуйте. Возник следующий вопрос: "Когда имеет смысл использовать представления?"

Навскидку, нашел такие случаи:
1. Какой-то запрос используется многократно как самостоятельно, так и как часть других более сложных запросов - в этом случае, чтобы "не пугать" программиста их можно "спрятать" за педставлением.
2. Часть данных создается динамически по хранящимся (например, несколько текстовых полей соединются в одно или над несколькими полями производятся какие-то вычисления) - хранить такие данные не очень хорошая идея из-за проблем с поддержанием их актуальности, а "заставлять" программиста знать тонкости их получения значит усложнять приложение.

Т.о., мой вопрос разбивается на три:
1. Прав ли я в своих рассуждениях?
2. Какие другие моменты применения представлений я упустил?
3. В какой книге про это можно почитать?

Заранее спасибо

Автор: Vit 9.4.2006, 14:59

Приведенные вами примеры в принципе работают но очень усложняют запросы... Это сильно сказывается на производительности. Вообще-то ответ будет таким - вообще не использовать нигде если без них можно обойтись. Есть 2 случая когда они очень нужны.

1. Для защиты данных
Например "Select Name From Table1" - пользователю даётся доступ к этому View, а не к исходной таблице и он не может оперировать никакими другими полями кроме Name, Или "Select * From Table Where UserID=3" - тогда пользователь будет иметь данные которые относятся только к нему. В целом именно это и служит причиной создания View в подавляющем большинстве случаев. Как правило вам надо дать ограниченный доступ к базе данных для другого програмимиста, например программисту из другой компании - партнёра, вам надо дать доступ только к определённым данным, вы создаёте вместо таблиц какое-то количество View и даёте ему доступ только к ним. Этот программист сможет полноценно работать с вашей базой - делать запросы, отчёты и т.п. но оперировать только теми таблицами, столбцами и колонками которые вы ему разрешили

2. Когда таблица состоит из результатов каких-то сложных функций, например

Create View N as
Select GetDate() as CurrentDate, NewId as RandomGuid

Автор: Bikutoru 10.4.2006, 10:39

Vit, спасибо за ответ. Как я понял, представление - это результат некоторого компромисса между программистом, которому не хочется писать сложные запросы, и пользователем, которому не хочется долго ждать отклика от приложения.

Автор: chief39 10.4.2006, 12:52

Цитата(Bikutoru @ 10.4.2006, 10:39

)

Vit, спасибо за ответ. Как я понял, представление - это результат некоторого компромисса между программистом, которому не хочется писать сложные запросы, и пользователем, которому не хочется долго ждать отклика от приложения.

ДА.
Что-то вроде компромисса между ассемблером и высокоуровневым ООП.

Кроме того, желая создать вьюху, помни о том, что из неё тоже придётся производить выборки. :-/
И если скрытие за вьюхой 10-табличного запроса со сложными вычислениями может быть оправдано, то две таблички в куче - вряд ли. "Селекционер" вместо 5 строк напишет 3, но до этого будет искать вьюху и разбираться с её назначением, дабы не "поймать" скрытую логическую бомбу.
Тем более "селекционеру" придётся знать и понимать не только стуктуру и смысл таблиц, а и структуры, смысл вьюх.
Кроме того вьюха нечасто будет универсальной. Каждому селекционеру может понадобиться что-то своё - придётся создавать целый "модельный ряд" вьюх, и знакомить с ним всех возможных "покупателей" smile

От таковских минусов накопал... хотя к вьюхам у меня вроде отношение ровное smile

Автор: batigoal 11.4.2006, 17:26

На нашем проекте была еще одна цель (изначально) - вьюхи использовались в качестве дополнтельного слоя абстракции. То есть приложение не должно было работать с таблицами напрямую. Благодаря этому мы могли бы впоследствии менять структуру таблиц без изменения приложения. Но впоследствии от этого отказались.