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

Откуда: ИТ-Олимп, 58.1-летний супермен
Сообщений: 3989
Тигра, не кипятись. Ну нравится некоторым гланды удалять через анальное отверстие - флаг в руки и барабан на шею.
9 мар 05, 16:48    [1372440]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324

Ну. Вы меня поразили!!!
Уж как я не думал, но так точно не представлял.
Вы не просто больше работы предпочитаете, вы предпочитаете двойную работу делать???!!!
Да, не слабо.
Вместо одной хп на одну операцию, вы делаете две - триггер и хп.
Теперь уж я не представляю, зачем это!!!
Почему вам простой, короткий и удобный способ не использовать? С клиента сразу дернуть хп - это что, так трудно?

Я еще раз повторю, что для приведенного скрипта мне без разницы дергать хп или вью.
В одном клиенте могу только ч/з хп работать, в другом только ч/з вью, в третьем и через то и через другое (зависит от механизма доступа) логика отработает одинаково.
Удобнее ч/з хп - пожалуйста, закрываю доступ ко всем вью, управляю правами хп.

Я не понимаю. Честно. Это чтоли как вера в КПСС - необъяснимо?

Вам легче писать вот ту путаницу? А какой смысл? Чтобы добавить один параметр, вам придется переписывать как минимум триггер и хп - вместо одной хп.

Вопрос поддержки и переписывания это уже из другой оперы. хп и триггеры у меня генерятся скриптом на основании модели в PD. Код триггеров генерится на 100%, он полностью формализованный (там нет никакой дополнительной бизнес-логики), код хп ~70%.
Так что трудоемкость для меня только в переписывании все той же одной хп для добавления параметра, а может и этого не быть.
И это не путаница. Здесь дается возможность выбора вместо отказа от той или иной методологии по идеологическим соображениям.

Тогда я уж не знаю, что еще можно сказать. Мы говорим на разных языках. Защита view немного (не совсем конечно :)) уже похожа на защиту dbf фокспрошниками.

А чем принципиально защита на основе хп отличается от защиты вью (именно для приведенного механизма)?
Для вью вы даете insert, update, delete, select (конечно от join и подзапросов защититься в mssql нельзя...)
Для хп:
exec sp_Ins
exec sp_Upd
exec sp_Del
exec sp_Select
exec sp_SelectList

Тигра, не кипятись. Ну нравится некоторым гланды удалять через анальное отверстие - флаг в руки и барабан на шею.

Вам наверное в "просто треп" уважаемый.

Posted via ActualForum NNTP Server 1.1

9 мар 05, 17:16    [1372563]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
kto-to
Member

Откуда: Ukraine, Kyev
Сообщений: 835
Роман Дынник
Я еще раз повторю, что для приведенного скрипта мне без разницы дергать хп или вью.
В одном клиенте могу только ч/з хп работать, в другом только ч/з вью, в третьем и через то и через другое (зависит от механизма доступа) логика отработает одинаково.

Есть одно существенное отличие:
в ТРИГГЕР никаких параметров ЯВНО передавать не нужно.
Это по-моему явный плюс.
9 мар 05, 18:19    [1372809]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Да как-то неаккуратненько получается :))

Дублирующийся код - ну не весь, но количество параметров, которые подпихиваются для хп в триггере. Но это фигня - можно и автоматом генерить

А кстати права то не получится разграничить таким подходом, когда ХП дергается из триггера. Я про те случаи, когда права это не просто тупые insert/update/delete/select, а когда права так же еще и бизнес-логика.
И получится, что ХП все-равно придется использовать с клиента.

А тогда зачем платить больше? :))

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

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

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

Откуда: Москва (Муром)
Сообщений: 74925
kto-to
Роман Дынник
Я еще раз повторю, что для приведенного скрипта мне без разницы дергать хп или вью.
В одном клиенте могу только ч/з хп работать, в другом только ч/з вью, в третьем и через то и через другое (зависит от механизма доступа) логика отработает одинаково.

Есть одно существенное отличие:
в ТРИГГЕР никаких параметров ЯВНО передавать не нужно.
Это по-моему явный плюс.


плюс по сравнению с чем??? Вы же в инструкцию INSERT на клиенте все равно "параметры" передавать будете при раюоте через вью.
9 мар 05, 18:21    [1372813]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Есть одно существенное отличие:
в ТРИГГЕР никаких параметров ЯВНО передавать не нужно.
Это по-моему явный плюс.

Вместо этого нужно на клиенте писать
insert table values ....
И в чем разница? :))

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

-- Tygra's --
9 мар 05, 18:22    [1372816]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
kto-to
Member

Откуда: Ukraine, Kyev
Сообщений: 835
pkarklin
Есть одно существенное отличие:
в ТРИГГЕР никаких параметров ЯВНО передавать не нужно.
Это по-моему явный плюс.

плюс по сравнению с чем??? Вы же в инструкцию INSERT на клиенте все равно "параметры" передавать будете при раюоте через вью.[/quot]

"плюс по сравнению" с простым вызовом процедуры.
Да, на клиенте пофиг куда параметры сувать.
Хотя будут случаи с массовыми операциями,
когда клиенту прийдется разгребать
куда и какие параметры надо сувать
(грубый пиример я уже приводил).
Тогда для случая с поцедурами прийдейтся
мутить режим пакетной обработки,
а триггер без моих дополнительных усилий
вытащит все, что нужно.

да, кстати, вспомнил еще...
Вся процедурная защита идет лесом
если я зашел как дбовнер этой базы
9 мар 05, 18:31    [1372836]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
VAT
Member

Откуда: Нижний Новгород
Сообщений: 295
Используем всё - вью, хп, разграничения доступа вплоть до строк и полей, изменения данных через хп и прямо. Контроль прав и данных в триггерах. Можно хоть через ЕМ править - ядро сломать не удастся.
В готовых отчётах - везде хп.
И вот задача: пользователю выбрать из десятков тысяч, (м.б. и миллионов) список нужных записей и их поправить через имеющийся интерфейс.
Причём критерий стал известен сегодня, сдавать завтра. Иначе ощутимый штраф, начиная сверху. Пользователь в стандартном интерфейсе выбирает свой сохранённый запрос, добавляет (джойнит) таблицы (вью), критерии отбора и вперёд править. Да, любой пользователь умеет пользоваться своими запросами (в разной степени, правда, но помогут). И ещё в обычном режиме надо работу делать.
А как получить нужный произвольный (т.е. непредвиденный) список записей без генерации запроса на клиенте?
Узнаю - от вью откажусь:-)
9 мар 05, 20:09    [1372998]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
Alexey Kudinov
Member

Откуда:
Сообщений: 13589
Что называется, встретились две темы https://www.sql.ru/forum/actualthread.aspx?tid=165804
VAT
Пользователь в стандартном интерфейсе выбирает свой сохранённый запрос, добавляет (джойнит) таблицы (вью), критерии отбора и вперёд править. Да, любой пользователь умеет пользоваться своими запросами (в разной степени, правда, но помогут). И ещё в обычном режиме надо работу делать.
А как получить нужный произвольный (т.е. непредвиденный) список записей без генерации запроса на клиенте?
AntonGart
Привет всем!
Мне тут показали прогу, где можно дать юзеру приложения самому генерировать where-часть запроса. Очень не понравилось... Но пока не могу найти весомых аргументов.
Приведите пожалуйста аргументы против этой идеи.
:)
9 мар 05, 20:18    [1373005]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
Shurgenz
Member

Откуда: Питер
Сообщений: 1938
Можно и мне пару слов?

1. Почему сравниваются только View и SP? Про функции забыли?

2. Исходя из дословного перевода: SP - Это процедура, хранящаяся на сервере (почему их просто не назвали процедурами?). Процедура - это некая логически обоснованная последовательность действий, не обязательно связанных с выборкой данных. Инструмент, ИМХО - универсальный. Можно сделать все, что хошь, но один и оч большой недостаток: НЕЛЬЗЯ ИСПОЛЬЗОВАТЬ В SELECT.

View - вид, или представление, нечто, преобразующее каким-либо образом данные из таблицы, таблиц, переде тем, как представить их пользователю. Или, скорее макрос, призванный облегчить труд по извлечению данных.

UDF - функции, могут быть и табличными, что делает их помощнее представлений. Две вещи, которые могут делать ХП, но не могут функции: Это инструкции DML (спорно, учитывая триггеры) и Динамические запросы.

Это все мое ИМХО. Но поступаю я исходя из написанного. ХП - инструмент, не предназначенный именно для выборки данных, но полезный для всего остального, View - несложные операции по отбору данных, UDF - Практически дополнение по функциональности ко View.
9 мар 05, 20:48    [1373029]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
kto-to

"плюс по сравнению" с простым вызовом процедуры.
Да, на клиенте пофиг куда параметры сувать.


Сами себе противоречите, где же плюс, когда "параметры все равно сувать"?!

kto-to

Хотя будут случаи с массовыми операциями,
когда клиенту прийдется разгребать
куда и какие параметры надо сувать
(грубый пиример я уже приводил).
Тогда для случая с поцедурами прийдейтся
мутить режим пакетной обработки,
а триггер без моих дополнительных усилий
вытащит все, что нужно.


Еще раз. Никаких пакетных обработок мутить не надо. Для режима массовой вставки (INSERT ... SELECT) заводят отдельную хп, с этим самым INSERT ... SELECT в ее теле, а не вызывают в курсоре процедуры с INSERT ... VALUES...

kto-to

да, кстати, вспомнил еще...
Вся процедурная защита идет лесом
если я зашел как дбовнер этой базы


Хорошая у Вас память. Вы бы еще вспомнили, что от sa совсем защититься нельзя. Ну и причем здесь это???
10 мар 05, 08:58    [1373360]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
VAT
Пользователь в стандартном интерфейсе выбирает свой сохранённый запрос, добавляет (джойнит) таблицы (вью), критерии отбора и вперёд править. Да, любой пользователь умеет пользоваться своими запросами (в разной степени, правда, но помогут). И ещё в обычном режиме надо работу делать.


Я, конечно, не Станиславский, но все равно скажу НЕ ВЕРЮ, чтоб "обычный" пользователь чего там "джоинил". Некоторые тетки и MDI интерфейс то не в силах освоить, а у Вас они знают схему данных и чего с чем джоинить надо.

VAT
А как получить нужный произвольный (т.е. непредвиденный) список записей без генерации запроса на клиенте?


Ээ... У Вас клиент - аналог QA?! Или мы все-таки говорим о некоей бизнес-системе, где "непредвиденный список записей" в большинстве означает только одно - плохую проработку предметной области.
10 мар 05, 09:07    [1373377]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
2 pkarklin : Пользователи умеющие джойнить существуют. Ошибка природы.Или последствия перестройки.

Правда для них существуют другие инструменты - экспортированные аксессные базы
10 мар 05, 09:34    [1373449]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
Shurgenz
Member

Откуда: Питер
Сообщений: 1938
prarklin:

а джойнить теткам то зачем? джойнить будет программер, что шелл для теток пишет. А теткам тока и надо, чтоб красиво и не глючило, да еще, чтоб как можно проще было в освоении, что не всегда просто в реализации... скажу так: чем проще с виду порой, тем гиморней в написании.
10 мар 05, 09:48    [1373497]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
Shurgenz
prarklin:

а джойнить теткам то зачем? джойнить будет программер, что шелл для теток пишет. А теткам тока и надо, чтоб красиво и не глючило, да еще, чтоб как можно проще было в освоении, что не всегда просто в реализации... скажу так: чем проще с виду порой, тем гиморней в написании.


Еще раз позволю себе повториться. Пользователю-программисту не надо ничего "джоинить" - за него уже все "проджоинил и с оптимизировал" разработчик бд. Даже в случаи, если разработчик бд и программер клиента - одно и тоже лицо, то на первом этапе проектируются база (не только таблицы, но и вся ее логика работы (хп, триггера и т.п)) и только потом пишется клиент. У Вас, похоже, все идет в параллель.
10 мар 05, 09:59    [1373537]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
Shurgenz
Member

Откуда: Питер
Сообщений: 1938
Без параллели не выходит. Только напишешь логику БД с таблицами, связями, функциями, процедурами, представлениями, логинами, ролями... и пр... Напишешь шелл, покажешь, говорят: надо бы ишо то-то и то-то. Иной раз вся логика к чертям собачьим. Править приходится, опять все продумывать с учетом сменившихся трабований (за которые порой и не платят).
10 мар 05, 10:07    [1373554]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Баааа кто-то реинкарнировал
Теперь SQL-ем жить мешаем :)

kto-to

да, кстати, вспомнил еще...
Вся процедурная защита идет лесом
если я зашел как дбовнер этой базы


В этом случае ЛЕСОМ идет абсолютно ЛЮБАЯ защита
10 мар 05, 10:11    [1373576]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
tygra
Member

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

VAT
И вот задача: пользователю выбрать из десятков тысяч, (м.б. и миллионов) список нужных записей и их поправить через имеющийся интерфейс.
Причём критерий стал известен сегодня, сдавать завтра. Иначе ощутимый штраф, начиная сверху. Пользователь в стандартном интерфейсе выбирает свой сохранённый запрос, добавляет (джойнит) таблицы (вью), критерии отбора и вперёд править. Да, любой пользователь умеет пользоваться своими запросами (в разной степени, правда, но помогут). И ещё в обычном режиме надо работу делать.
А как получить нужный произвольный (т.е. непредвиденный) список записей без генерации запроса на клиенте?

Что же дальше?
----------------------------------------------------------

Я чтойто пока не вижу доказательств того, что нельзя все делать на ХП. Может зря жду? :))


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

Откуда: Питер
Сообщений: 1938
Tigra:

Да все можно делать, только в селект не ставь
10 мар 05, 10:46    [1373713]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
VAT
Member

Откуда: Нижний Новгород
Сообщений: 295
автор
мы все-таки говорим о некоей бизнес-системе, где "непредвиденный список записей" в большинстве означает только одно - плохую проработку предметной области

Видимо, я о другой бизнес-системе. Существуют предметные области, которые не удаётся проработать хорошо по причине их частой, внезапной и значительной переменчивости. И ограниченности ресурсов. Удаётся по-хорошему проработать ядро и базовые функции системы.
Построитель запросов сделан вполне понятным, начальники отделов и продвинутые пользователи строят нужные сохранённые запросы и раздают их сотрудникам. Им остаётся выбрать из списка по названию и вписать параметры. Посложнее запрос программисты помогут сделать.
автор
НЕ ВЕРЮ, чтоб "обычный" пользователь чего там "джоинил".

Слово "джойн" они, конечно, не знают, но фраза "выбрать документы, где в проводках счёт по дебету содержит 12345%" для них понятна.

автор
самому генерировать where-часть запроса. Очень не понравилось...

Не только where, но и from. Кому не понравилось, юзеру? Что его проблема быстро решается? Без заявки на доработку, и что ночью ему сидеть не нужно?
Наверное, реализация той "проги" была не хороша.

А может, юзера у нас действительно какие-то уникальные.
10 мар 05, 12:29    [1374215]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
VAT
Не только where, но и from. Кому не понравилось, юзеру? Что его проблема быстро решается? Без заявки на доработку, и что ночью ему сидеть не нужно?


представляю, чего может сотворить юзер с такой системой, примерно так:

SELECT * FROM sysobjects s1, sysobjects s2, sysobjects s3... sysobjects sN
.

10 мар 05, 12:34    [1374246]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
aag
Member

Откуда: Москва
Сообщений: 1955
Существуют предметные области, которые не удаётся проработать хорошо по причине их частой, внезапной и значительной переменчивости. И ограниченности ресурсов.

Если вы имели в виду, что нельзя учесть и реализовать все потребности юзеров в отчетах, то согласен. Если же вы хотите сказать, что из-за переменчивости бизнеса его нельзя автоматизировать в принципе - то никакие построители здесь уже не помогут. Хотя я о таких областях не слышал.

Построитель запросов сделан вполне понятным, начальники отделов и продвинутые пользователи строят нужные сохранённые запросы и раздают их сотрудникам

Видел несколько попыток создать такие построители, но ни разу не видел чтобы оказался востребованным. И этому есть обьяснения:
1) После простых запросов пользователям всегда хочется сложных. Со сложными программисты помогут? - И прекрасно, значит они и простые пусть сделают, мы-то в конце концов не программисты, мы пользователи.
2) Пользователи не только не знают SQL - это-то ладно. Но они также не знают и теорию реляционных баз данных, не знают что такое PK, FK, ограничения целостности и многое другое. И не обязаны знать. А идеальный по гибкости/мощности построитель - это QA.

Роман Дынник
А чем принципиально защита на основе хп отличается от защиты вью (именно для приведенного механизма)?
Для вью вы даете insert, update, delete, select (конечно от join и подзапросов защититься в mssql нельзя...)
Вы путаете систему прав самого MSSQL (grant/revoke на пользователей) и систему прав, придуманную для прикладной системы. Которая может быть произвольно сложной. К примеру, захочет Самый Главный Начальник, чтобы по четным часам доступ к счетам-проводкам-документам (не таблицам! бизнес-сущностям) был, а по нечетным - не был :)

Описанный вами способ вызова ХП из триггера выгоден лишь тогда, когда вы хотите использовать встроенные dbaware-механизмы - т.е., которые сами автоматически будут слать инструкции insert/update/delete на сервер. Такая схема, безусловно, имеет право на жизнь (и иногда даже выгодна), но в большинстве случаев очень геморройна и ненадежна. Достаточно поискать в форумах кол-во налетевших на грабли, связанных с отсутствием SET NOCOUNT.


Nobody faults but mine... (LZ)
10 мар 05, 13:57    [1374681]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
VAT
Member

Откуда: Нижний Новгород
Сообщений: 295
автор
представляю, чего может сотворить юзер с такой системой, примерно так:

SELECT * FROM sysobjects s1, sysobjects s2, sysobjects s3... sysobjects sN


Из прикладного интерфейса не может, список таблиц, вью для соединения фиксирован в отдельной таблице, как и способ соединения.
Из QA может, будет найден, убит и наказан (посмертно):-)
10 мар 05, 14:48    [1375001]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
VAT
Из QA может, будет найден, убит и наказан (посмертно):-)


Посмертно имелось ввиду после смерти системы? А не было у пользователя бы доступа к таблицам совсем и наказывать не кого было бы и не за что.
10 мар 05, 14:52    [1375015]     Ответить | Цитировать Сообщить модератору
 Re: ХП против View  [new]
aag
Member

Откуда: Москва
Сообщений: 1955
автор
Из прикладного интерфейса не может, список таблиц, вью для соединения фиксирован в отдельной таблице, как и способ соединения


А, ну тогда вместо программирования запросов для юзеров вы бесперерывно должны заниматься программированием построителя для них.

Nobody faults but mine... (LZ)
10 мар 05, 16:01    [1375442]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить