Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8   вперед  Ctrl      все
 ХП против View  [new]
Alexander2
Member

Откуда: Calgary
Сообщений: 1165
объясните плиз разницу между подходами

1) я имею хранимую процедуру следущего содержания
автор

CREATE proc dbo.SpListFull
@list varchar(8000)
as
declare @Query nvarchar(4000)

set @Query =
N'insert into #MyTmp
select
fu.Id_Code,
pm.Id_LSD,
fu.Big_Image,
fu.PhotoName,
fu.DateEdit,
pm.Id_Order,
fu.Extension

from BigProjectPhotos fu inner join P_Images pm
on fu.Id_Code=pm.Id_BigPhoto
where fu.Id_Code in ('+@mylist+N')'
exec sp_executesql @Query
set @Query =
N'select Id_Code,
LSD, LargePhoto,
PhotoName, DateEdit,
Id_Order, Extension
from #MyTmp order by LSD, Id_Order'
exec sp_executesql @Query
return @@error
GO


и вызываю в программе ее для наполнения датасета данными

2) я имею View следущего содержания
и вызываю ее для наполнения датасета данными
[quot автор]
CREATE VIEW dbo.VIEW1
AS
SELECT
P_Images.Id_Project AS Expr1,
P_Subject.subject,
P_Images.Id_Site,
P_Images.Is_Checked,
P_Images.Id_Code,
BigProjectPhotos.Big_Image,
P_Images.Id_LSD,
P_Images.PhotoName,
P_Images.DateEdit,
P_Images.Id_Order,
P_Images.Extension
FROM P_Images
INNER JOIN BigProjectPhotos ON P_Images.Id_Code = BigProjectPhotos.Id_Code
LEFT OUTER JOIN Project_Subject ON P_Images.Id_Code =Project_Subject.Id_Code
WHERE (P_Images.Is_Checked = 1)
[/quot

Я посмотрел - по времени работы приложения - никакой разницы (может доля секунды) - вытаскивает фотки одинаково

Где у кого какое преимущество? И вообще что лучше?
4 мар 05, 00:04    [1361795]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
Alex Antonoff
Member

Откуда: Из лесу вестимо
Сообщений: 1251
Я предпочитаю ХП, потому что они скрывают за собой реально существующую структуру данных и позволяют относительно безболезненно ее менять. При этом во вьюшке для обеспечения совместимости со временем могут появиться очень страшные и не эффективные запросы, в то время как ХП позволяет мне для каждого конкретного случая написать наиболее эффективный код, просто потому что действие ХП ограничено.
4 мар 05, 06:23    [1361912]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
Adony
Member

Откуда: Москва
Сообщений: 1083
2Alex Antonoff
...что действие ХП ограничено
Простите, в чем?
4 мар 05, 06:27    [1361916]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
Alex Antonoff
Member

Откуда: Из лесу вестимо
Сообщений: 1251
Просто по сути, хп - выполняет вполне конкретную функцию, а вьюшка может обьеденяться в тысяче самых разных мест и везде по разному
4 мар 05, 06:38    [1361922]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
Adony
Member

Откуда: Москва
Сообщений: 1083
В этом смыле, понял.
4 мар 05, 06:45    [1361925]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
Alexander2
Member

Откуда: Calgary
Сообщений: 1165
Может я неудачный пример привел, уже исправил свою ХП и вьюху, но дело в принципе.

Вот в одном клиент-серверном приложении я большой упор сделал на заранее заготовленные Views и использовал их в получении данных на датасеты.

Но тоже самое можно сделать с использованием только ХП, в них создаются по-существу те же датасеты, они также hardкодированы, выполняются сервером (делают, например, то же, что и вьюхи).

В чем тогда разница?

Одну я вижу - если поменять наименование поля в базе данных - то приходится менять это во всех управляющих скриптах что во вьюхах, что в ХП.
Но я заметил, что иногда очевидная ошибка не всплывает сразу (если много наплодилось вьюх) вроде приложение работает, юзает первые 25-50% часто используемых вьюх. Если там забыл поменять название поля - то ошибка всплывает сразу а вот про остальное семейство уже не скажешь, называется не тронь г - не воняет - то есть нет проблем пока не вызовет кто-то редко используемую вьюху.

А если все описывается через ХП - то ошибка генерится раньше - и не так болезненно вроде как - взял да поменял название поля в большой ХП - все успокаивается.

Снова скажут: с таким же успехом меняй во всех вьюхах название вовремя.
А как отлавливать в каких вьюхах я использовал то или иное поле?
Заманаешься каждую открывать и искать. Делаю скрипт и по скритпу ищу - быстрее получается.

В общем, вилами по воде базар. Пардон за флуд.
5 мар 05, 02:48    [1365626]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
StalkerS
Member

Откуда: Nowhere
Сообщений: 1343
Alexander2

Но тоже самое можно сделать с использованием только ХП, в них создаются по-существу те же датасеты, они также hardкодированы, выполняются сервером (делают, например, то же, что и вьюхи).

В чем тогда разница?


Во-первых, разница в том, что для ХП храниться скомпилированный план запроса, а для представления - нет. Оно вообще храниться просто
как текст, который надо вставить в другой запрос. Поэтому использование ХП для получения данных выгоднее по определению.

Во-вторых, это вообще вещи для немного разных задач. ХП может выполнять какие-нибудь действия в базе, возращать данные. Представления-же
предназначены для уменьшения видимой сложности базы (т.к. преставление я могу воткнуть в другой запрос, обьединить с другой таблицей
в запросе, а ХП - нет), для разграничения доступа, т.е. можно дать определенному пользователю права на чтение и изменение только определенной
информации, а ХП - в основном только на чтение. Наконец, если позарез нужно увеличение производительности - представление можно индексировать,
т.е. по-сути денормализовать базу.
5 мар 05, 09:17    [1365862]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Во-вторых, это вообще вещи для немного разных задач. ХП может выполнять какие-нибудь действия в базе, возращать данные. Представления-же
предназначены для уменьшения видимой сложности базы (т.к. преставление я могу воткнуть в другой запрос, обьединить с другой таблицей
в запросе, а ХП - нет), для разграничения доступа, т.е. можно дать определенному пользователю права на чтение и изменение только определенной
информации, а ХП - в основном только на чтение. Наконец, если позарез нужно увеличение производительности - представление можно индексировать,
т.е. по-сути денормализовать базу
.

Что-то немного не совсем то :)

View - это лишь способ объеденить несколько таблиц для дальнейшего использования. В основном. Можно конечно права раздавать - но я так не делаю ни с таблицами, ни с view.

ХП - это полностью универсальная вещь.
С помощью ХП можно так же выдавать результат запроса. Так же, да не так: если вам нужно перед выборкой произвести некоторые вычисления и передать результат в выборке или произвести еще несколько подготовительных выборок - то view тут никак не поможет, в ХП же это все естественно делается и никто, вызывающий ХП, ничего этого не видит и более того, во всех местах он вызывает одну и ту же ХП, а не дублирует килобайты кода, что вообще в купе с подготовительными операциями приведет к путанице - ведь не надо забывать, что если чего-то нужно поменять, то легче это сделать один раз в ХП, чем 45 раз по всем вызовам view в приложении и не только.
Еще ХП хорошо применять при модификациях данных - опять же много разных действий можно скрыть в одной процедуре.
Ну и не забывать про права - используя ХП, права на таблицы у юзера не нужны и не должны быть, только на выполнение ХП. Поэтому юзер в БД ничего не сможет сделать, получа доступ через что бы то ни было и сделать что-то в обход логики.
Ну и конечно скомпилированный код ХП - ох как влияет на производительность.

2 Alexander2
Что-то код приведенных ХП у вас странный. Зачем вам там вообще exec sp_executesql ?

-- Tygra's --
5 мар 05, 10:15    [1366013]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
StalkerS
Member

Откуда: Nowhere
Сообщений: 1343
tygra

Можно конечно права раздавать - но я так не делаю ни с таблицами, ни с view.


ну, то что вы это не делаете, еще не говорит о том, что это делать не следует ;)

вот например, один пользователь должен иметь доступ только к данным таблицы, где х=1, а другой - где х=2.
Причем не только читать, но и изменять, и без всяких доп. вычислений. Делаем два представления - и идем
пить пиво.
Можно конечно это и через ХП сделать, только не нужно ;)

tygra

то легче это сделать один раз в ХП, чем 45 раз по всем вызовам view в приложении


в принципе, ничего не мешает вычисления забить в определение view (с рядом ограничений), и не дублировать их 45 раз на клиентах.
И хотя ХП тут побыстрее будет, иногда представление может оказаться лучше, например если надо обьединять результат с другой
таблицей. В общем, смотреть по обстоятельствам надо, не существеут универсальных рецептов на все случаи жизни
5 мар 05, 10:38    [1366089]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
В плюсы view

1. самодокументированность. Т.е. пользователю очевидно как с ними работать
так как они обладают семантикой таблиц и, если нужно, обеспечивают прозрачную поддержку CRUD-операций (create/update/delete)
2. являются стандартным средством БД. Фактически это объект, с которым все могут работать как с таблицей. Отсюда прямая поддержка всего чего только можно (например, репликации).
3. представляют собой естественный способ для обеспечения базовой безопасности БД (т.е. безопасности для select/insert/update/delete данных базовых таблиц)
4. обеспечивают простую и прозрачную инкапсуляцию базовой схемы БД. Да, хранимые процедуры позволяют делать эту еще более инкапсуляцию изощренно - НО для перечисленных мною операций, за реализацию которых могут отвечать view, возможности SP обычно излишни.
5. есть в большинстве современных СУБД.
6. поддерживаются всеми средствами доступа к БД (ODBC/JDBC/ADO/ADO.net и т.д.)
7. предполагают дальнейшую оптимизацию при использовании в качестве подзапросов в других запросах.

Т.е. я за использование представлений для обеспечения CRUD-операций для объектов БД. И я за ХП при реализации других бизнес-действий над этими объектами.
5 мар 05, 10:50    [1366139]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
Лео
Member

Откуда: Москва
Сообщений: 207
Вопрос в сложности задачи.
автор=StalkerS
вот например, один пользователь должен иметь доступ только к данным таблицы, где х=1, а другой - где х=2
если случаев всего 2 и приложение простое, то можно сразу получить из вьюхи. А если случаев много, доступом управляют выделенные для этого пользователи, причем меняются они 10 раз за день, то ХП по любому. Вьюхи генерить на это сложно (права не пользовательские на удаление), да и иметь БД с непонятным кол-вом объектов тоскливо.
5 мар 05, 11:08    [1366205]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
А я вот только за ХП.
В смысле, view могут быть, но используются только внутри ХП. А у юзеров есть только права на ХП - и ни на одну таблицу или view.
Так гораздо проще с правами обходиться. Гораздо проще. И удобнее.

Но собственно по вопросу - если внутри ХП селектить view, то одна фигня :)

-- Tygra's --
5 мар 05, 11:11    [1366216]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
Так гораздо проще с правами обходиться. Гораздо проще. И удобнее.

Не, tygra, неправда твоя... Никаких сложностей при раздаче прав на view нет, даже наоборот...
5 мар 05, 11:14    [1366228]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
2 Лео
Можно еще добавить к этому:
если нет никаких x=1 или x=2, но зато в одном случае пользователю можно работать с таблицей, а в другом нельзя (да еще таких случаев сотни) - то тут кроме как прав на ХП ничего не поможет.

-- Tygra's --
5 мар 05, 11:15    [1366239]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37101
tygra
А я вот только за ХП.
В смысле, view могут быть, но используются только внутри ХП. А у юзеров есть только права на ХП - и ни на одну таблицу или view.
Так гораздо проще с правами обходиться. Гораздо проще. И удобнее.

Но собственно по вопросу - если внутри ХП селектить view, то одна фигня :)

-- Tygra's --

Я тоже за этот подход. Ну их, эти вьювы. :)
5 мар 05, 11:16    [1366243]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Не, tygra, неправда твоя... Никаких сложностей при раздаче прав на view нет, даже наоборот...

Вот выше я привел пример. Никак через view он не решается. Ну если только не добавлять на каждый случай по view - но это уже за пределами научной фантастики. К тому же я еще не видел, чтобы работа с таблицей ограничивалась только командой insert/delete/update - обязательно выпоняется куча других действий и не с одной таблицей. А тут уж никак без ХП. И соответсвенно лучше вообще отказаться от работы с данными не через ХП - чтобы была одинаковая процедура работы в системе и чтобы не плодить кучу ненужных view и ХП, которые используются в разных сочетаниях - это будет кошмаррррррррр

-- Tygra's --
5 мар 05, 11:19    [1366263]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
tygra

К сожалению не понял твоего примера.

А так - господа, давайте не будем переходить к holly war - только сухие доводы!
5 мар 05, 11:26    [1366299]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
Насчет плодить view и sp вместо одних sp

Не вижу проблем - view- инкапсулируют схему и базовые операции с объектами (CRUD). SP служат реализации других действий.

Кроме того - для большинства объектов схемы ничего кроме CRUD обычно не требуется.
И еще, я не считаю кучу автоматом сгенеренных ХП с одной строчкой типа insert или select для CRUD операций красивым решением.

Вот что я имею в виду
CREATE VIEW scheme_owner.v_employee
AS
SELECT .. FROM scheme_owner.employee

Включает функциональность вот этого
CREATE STORED PROCEDURE scheme_owner.select_employee
@employee ...
AS
select ... from scheme_owner.employee where id=@employee
go
CREATE STORED PROCEDURE scheme_owner.insert_employee
@employee ...
AS
insert into scheme_owner.employee (...) values(...)
go
CREATE STORED PROCEDURE scheme_owner.update_employee
@employee ...
AS
update scheme_owner.employee set ... where id=@employee
go
CREATE STORED PROCEDURE scheme_owner.select_employee
@employee ...
AS
delete from scheme_owner.employee where id=@employee
go
Неужели это может казаться лаконичнее чем view?

Но это еще не все - в случае view я могу написать
select * from scheme_owner.v_employee where first_name='...'

И это не будет нарушать ни инкапсуляции ни безопасности и не требовать написания ни строчки кода. В случае же SP нужно будет писать еще по процедуре для каждого вида запросов!
5 мар 05, 11:37    [1366348]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
К сожалению не понял твоего примера.

А так - господа, давайте не будем переходить к holly war - только сухие доводы!

Щас расскажу. Никаких войн - нафиг надо :)
Но получается, что речь пошла уже не о view и ХП, а о принципах работы с данными: TSQL на клиенте или в ХП.

автор
Не вижу проблем - view- инкапсулируют схему и базовые операции с объектами (CRUD). SP служат реализации других действий.

ХП могут послужить и остальному :)

автор
Кроме того - для большинства объектов схемы ничего кроме CRUD обычно не требуется.

Я могу предположить, что в 50% случаев ничего кроме insert into table .. values (..) (или delete/update) не потребуется больше ничего.
Но в остальных случаях перед этим или после этого нужно сделать еще много чего и не только с этими таблицами. Делать это все с клиента - извините, спасибо, я от такой системы убегу подальше - рыться в исходниках клиента, что поправить пару строк, и так каждый раз.... Нееет, я на такое не согласен. Я лучше изменю одну ХП, один раз, и то на сервере - и все, никаких проблем.
То же самое для select - тут вообще может быть больше 50% случаев, когда нужно что-то делать еще, и в гораздо больших местах это придется править на клиенте, потому что выборка данных встречается намного чаще, чем их изменение.

автор
И еще, я не считаю кучу автоматом сгенеренных ХП с одной строчкой типа insert или select для CRUD операций красивым решением.

Почему? Вы считаете красивым решением кучу скриптов на клиенте? Которые править придется как описано выше? Чем это лучше, чем ХП? А если сегодня только insert, а вдруг завтра нужно перед инсертом чего-то посчтитать - вы опять в клиента полезете? Мне такая головная боль не нужна - я правлю одну ХП и отдыхаю :)

автор
Неужели это может казаться лаконичнее чем view?

Конечно! Да и при чем тут view? Тут что view, что table, одна фигня.

автор
Но это еще не все - в случае view я могу написать
select * from scheme_owner.v_employee where first_name='...'

И это не будет нарушать ни инкапсуляции ни безопасности и не требовать написания ни строчки кода. В случае же SP нужно будет писать еще по процедуре для каждого вида запросов!

Ну как так, строчку кода по крайней мере вы уже написали :))
По процедуре для каждого вида - это уж слишком, у ХП параметры есть, туда можете передавать все, что хотите, и получать соответственно. Но зато если перед селектом вам чего-то нужно делать, то вы это будете писать столько раз, сколько у вас будет запросов, а я в ХП напишу один раз и забуду.

И про пример.
Есть клиент. Есть таблица, и не одна, которая представляет данные клиента.
Есть оператор. Дык вот в одной ситуации оператор может посмотреть данные клиента - и не может ничего изменить. А в другой ситуации оператор может что-то поменять у клиента - но только в этой ситуации. Как вы будете выдавать права? Делать разные view для этих ситуаций? А ситуаций 100. 100 view? Или будете вызывать ХП? А смысл - ведь права у юзера есть уже на изменение где-то, значит он может изменять клиента везде? Как вы их отберете? И кто мешает мне зайти в БД и поменять через view что хочу и где хочу? Будете делать ХП? Ну тогда будет каша - в одеом месте view, в другом ХП, опять же права уже есть на изменение, хоть и через view, но есть.

Только ХП же решает это полностью - в одном месте вызывается одна ХП, в другом - другая, права на них есть или нет, на таблицу или view прав нет вообще. Юзер может работать только в пределах прав на исполнение ХП.

Что это дает в целом?
1. Изменение логики происходит всегда в одном месте - на сервере в ХП, причем быстро, без правки клиента, причем легко унифицировать эти процессы.
2. Права на выполнение дают работу только в заданных архитектурой системы местах.
3. Подход к работе с данными полностью унифицирован - не нужно помнить, где править на клиенте, где на сервере, где еще....
4. Это удобно.
5. Что не исключает использование view внутри ХП в том объеме, который необходим.

-- Tygra's --
5 мар 05, 12:06    [1366465]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
ChA
Member

Откуда: Москва
Сообщений: 11128
StalkerS
для ХП храниться скомпилированный план запроса
Знаю компилированный код, знаю, что он появляется в кэше после первого запуска процедуры и остается там, пока не будет вытеснен, знаю план запроса, который обычно также строится при первом вызове процедуры, но чтобы скомпилированный план запроса, да еще который храниться ? Ссылочку на источник знаний не укажете ? Может что-то пропустил ?
5 мар 05, 12:08    [1366477]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
tygra

Насчет твоего примера. Я думаю ты просто забыл что для view permission'ы раздаются для каждой из операций отдельно (+еще и DRI). Таким образом твоя задача - это как раз для view.

Создаем представление scheme_owner.v_employee
Создаем 2 роли типа employees_reader и employees_writer
Даем первой роли права на select из scheme_owner.v_employee
Даем второй роли права на update/delete/insert в scheme_owner.v_employee
Включаем нужных пользователей в нужные роли

Разве не красиво?


Теперь насчет генерации чего-то с клиента. Я ничего не генерю. В общем это вопрос на тему нужно ли чтобы действие insert делало что-то еще кроме непосредственно инсерта? Я на него ответил отрицательно. Соотвественно никаких действий в нем я обычно не делаю.
5 мар 05, 12:20    [1366525]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Насчет твоего примера. Я думаю ты просто забыл что для view permission'ы раздаются для каждой из операций отдельно (+еще и DRI). Таким образом твоя задача - это как раз для view.

Создаем представление scheme_owner.v_employee
Создаем 2 роли типа employees_reader и employees_writer
Даем первой роли права на select из scheme_owner.v_employee
Даем второй роли права на update/delete/insert в scheme_owner.v_employee
Включаем нужных пользователей в нужные роли

Разве не красиво?

Не красиво и не годится :)
Есчо раз повторяю пример:
Юзер имеет обе эти роли! Но в форме А он может менять данные, а в форме Б - не может. Это один и тот же юзер. Как вы это решите?


-- Tygra's --
5 мар 05, 12:33    [1366588]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
Не понял. Что значит в форме А и в форме Б? Т.е. пользователь имеет бизнес-необходимость и возможность выполнить действие, но просто в разных экранных формах ему эту возможность необходимо запретить? А это разве не проблема пользовательского интерфейса?
5 мар 05, 12:35    [1366598]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
funikovyuri
Не понял. Что значит в форме А и в форме Б? Т.е. пользователь имеет бизнес-необходимость и возможность выполнить действие, но просто в разных экранных формах ему эту возможность необходимо запретить? А это разве не проблема пользовательского интерфейса?


да, проблема пользовательско интерфейса, но решать её удобнее на сервере :)
5 мар 05, 12:46    [1366660]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
StalkerS
Member

Откуда: Nowhere
Сообщений: 1343
ChA

но чтобы скомпилированный план запроса, да еще который храниться ?


скомпилированный код запроса, разумеется. А планы они вообще храняться для любого исполненного оператора sql, так что ХП там не имеют преимуществ.
5 мар 05, 12:46    [1366663]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить