В чем разница между хранимой процедурой и видом?
Я запутался в нескольких пунктах:
в чем разница между хранимой процедурой и видом?
когда следует использовать хранимые процедуры и когда следует использовать представления в SQL Server?
позволяют ли представления создавать динамические запросы, где мы можем передавать параметры?
какой из них самый быстрый, и на каком основании один быстрее, чем другие?
выделяют ли представления или хранимые процедуры память постоянно?
Что это значит, если кто-то говорит, что представления создают виртуальную таблицу, а процедуры создают таблицу материалов?
пожалуйста, дайте мне знать больше очков, если таковые имеются.
10 ответов:
вид представляет собой виртуальный таблица. Вы можете объединить несколько таблиц в представлении и использовать представление для представления данных, как если бы данные поступали из одной таблицы.
хранимая процедура использует параметры для выполнения функции... будь то обновление и вставка данных или возврат отдельных значений или наборов данных.
создание представлений и хранимых процедур - есть информация от Microsoft о том, когда и зачем использовать каждый.
скажем, у меня есть две таблицы:
tbl_user Столбцы: .идентификатор пользователя, .имя пользователя, .user_pw
tbl_profile Столбцы: .идентификатор профиля, .идентификатор пользователя .profile_description
так что если я нахожу себя запрос из этих таблиц много... вместо того, чтобы делать соединение в каждом пейсе sql, я бы определил представление как:
CREATE View vw_user_profile AS Select A.user_id, B.profile_description FROM tbl_user A left join tbl_profile B on A.user_id = b.user_id GOтак что в будущем, если я хочу запросить profile_description по идентификатору пользователя... все, что мне нужно это
SELECT profile_description FROM vw_user_profile WHERE user_id = @IDэтот код может быть использован в хранимой процедуре, например:
create procedure dbo.getDesc @ID int AS begin SELECT profile_description FROM vw_user_profile WHERE user_id = @ID END GOтак что позже я могу назвать
dbo.getDesc 25и я получу описание для id пользователя 25. где 25-это ваш параметр.
там, очевидно, гораздо больше деталей, но, это только основная идея.
много информации, доступной в интернете, как этой
вот хорошее резюме:
Хранимая Процедура:
- параметры
- можете не используется в качестве строительного блока в большем запросе
- может содержать несколько высказываний, петель, если еще и т. д.
- может выполнять изменения в одной или нескольких таблицах
- не может быть использован в качестве цели Вставка, обновление или удаление заявление.
Вид:
- не принимает параметры
- может использоваться в качестве строительного блока в большем запросе
- может содержать только один запрос SELECT
- не может выполнять изменения в любой таблице
- но может (иногда) использоваться в качестве цели вставки, обновления или инструкция Delete.
сначала вам нужно понять, что это разные вещи. Хранимые процедуры лучше всего использовать для инструкций INSERT-UPDATE-DELETE. и представления используются для операторов SELECT. и вы должны использовать оба.
в представлениях вы не можете изменить данные.некоторые базы данных имеют обновляемые представления, где вы можете использовать INSERT-UPDATE-DELETE на представлениях.
вид-это простой способ сохранить сложную
SELECTв базе данных.процедура хранения используется, когда простой SQL просто не достаточно. Хранимые процедуры содержат переменные, циклы и вызовы других хранимых процедур. Это язык программирования, а не язык запросов.
представления статичны. Думайте о них как о новых таблицах с определенным макетом, и данные в них создаются на лету с помощью запроса, с которым вы его создали. Как и в любой таблице SQL, вы можете сортируйте и фильтруйте его с помощью
WHERE,GROUP BYиORDER BY.все зависит от того, что вы делаете.
зависит от базы данных. Простые представления просто запускают запрос и фильтруют результат. Но базы данных, такие как Oracle, позволяют создавать "материализованное" представление, которое в основном представляет собой таблицу, которая обновляется автоматически при изменении базовых данных представления.
материализованное представление позволяет создавать индексы на столбцах смотреть (особенно на вычисляемые столбцы, которые не существуют нигде в базе данных).
Я не понимаю, о чем ты говоришь.
представление SQL-это виртуальная таблица, основанная на запросе SQL SELECT. Представление ссылается на одну или несколько существующих таблиц базы данных или других представлений. Это мгновенный снимок базы данных, в то время как хранимая процедура представляет собой группу инструкций Transact-SQL, скомпилированных в единый план выполнения.
посмотреть простой демонстрации данных, хранящихся в таблицах базы данных, в то время как хранимая процедура-это группа операторов, которые могут быть выполнены.
представление быстрее, поскольку оно отображает данные из таблицы, на которые ссылаются, в то время как процедура хранилища выполняет инструкции sql.
проверить эту статью : просмотр vs хранимые процедуры . Именно то, что вы ищете
- представление-это динамический запрос, в котором вы можете использовать предложение "WHERE" -
- хранимая процедура-это фиксированный выбор данных, который возвращает предопределенный результат
- ни представление, ни хранимая процедура выделения памяти. Только материализованный вид
- таблица-это всего лишь одна сущность, представление может собирать данные из разных сущностей или таблиц
основное отличие заключается в том, что когда вы запрашиваете представление, то его определение вставляется в ваш запрос. Процедура также может дать результаты запроса, но она компилируется и так быстрее. Другой вариант-индексированные представления..
@Patrick прав с тем, что он сказал, но чтобы ответить на ваши другие вопросы, представление создаст себя в памяти, и в зависимости от типа соединений, данных и если есть какая-либо агрегация, это может быть довольно голодное представление памяти.
хранимые процедуры выполняют всю свою обработку либо с помощью временной хэш-таблицы, например #tmpTable1, либо в памяти с помощью @tmpTable1. В зависимости от того, что вы хотите сказать этим делать.
хранимая процедура похожа на функцию, но вызывается напрямую по его имени. вместо функций, которые используются внутри самого запроса.
очевидно, что большинство таблиц памяти времени быстрее, если вы не извлекаете много данных.
Махеш не совсем правильно, когда он говорит о том, что вы не можете изменить данные в представлении. Так что с точки зрения Патрика
CREATE View vw_user_profile AS Select A.user_id, B.profile_description FROM tbl_user A left join tbl_profile B on A.user_id = b.user_idЯ могу обновить данные ... в качестве примера я могу сделать любой из этих ...
Update vw_user_profile Set profile_description='Manager' where user_id=4или
Update tbl_profile Set profile_description='Manager' where user_id=4вы не можете вставить в это представление, поскольку не все поля во всей таблице присутствуют, и я предполагаю, что PROFILE_ID является первичным ключом и не может быть NULL. Однако иногда вы можете вставить в представление ...
I создал представление для существующей таблицы с помощью ...
Create View Junk as SELECT * from [TableName]затем
Insert into junk (Code,name) values ('glyn','Glyn Roberts'), ('Mary','Maryann Roberts')и
DELETE from Junk Where ID>4и вставка, и удаление работали в этом случае
очевидно, что вы не можете обновить какие-либо поля, которые агрегируются или вычисляются, но любой вид, который является просто прямым видом, должен быть обновлен.
если представление содержит более одной таблицы, то вы не можете вставить или удалить, но если представление является подмножеством только одной таблицы, то вы обычно мочь.
в дополнение к приведенным выше комментариям, я хотел бы добавить несколько моментов о представлениях.
- представления могут быть использованы для скрытия сложности. Представьте себе сценарий, когда 5 человек работают над проектом, но только один из них слишком хорош с такими вещами базы данных, как сложные соединения. В таком сценарии он может создавать представления, которые могут быть легко запрошены другими членами команды, поскольку они запрашивают любую отдельную таблицу.
- безопасность может быть легко реализована с помощью представлений. Предположим, у нас есть таблица сотрудник, который содержит чувствительные колонки, как зарплата,номер SSN. Эти столбцы не должны быть видны пользователям, которые не имеют права их просматривать. В таком случае мы можем создать представление, выбирая столбцы в таблице, которая не требует никакой авторизации, как имя,возраст и т. д., не подвергая чувствительные столбцы (например, зарплата и т. д. мы уже упоминали ранее). Теперь мы можем удалить разрешение на прямой запрос в таблице сотрудник и просто сохранить разрешение на чтение на вид. Таким образом, мы можем реализовать безопасность с помощью представлений.
Comments