Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
sp Member Откуда: Сообщений: 3947 |
Собираюсь в ASP.NET проекте использовать единую точку входа и исполнения запросов пользователей при помощи sp и переключения контекста EXECUTE AS <userLogin> Смысл в том чтобы продолжать пользоваться не именованным пулом соединений в ASP.NET приложении и разграничением прав пользователей при помощи креденций самого SQL Servera В связи с этим встает вопрос производительности такого решения. Насколько переключение контекста может отразится на производительности? |
15 окт 12, 17:54 [13322138] Ответить | Цитировать Сообщить модератору |
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37143 |
Эээ. А все другие проблемы производительности вы уже порешали? |
15 окт 12, 20:01 [13322658] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
Гавриленко Сергей Алексеевич, а я и не слышал о таком способе. ![]() Неужели массово используют? Меня например настораживает многое. Ибо не всегда и не везде используется проверка ассоциативного пользователя, иногда именно заходящего/первичного. Думаю что это лучше именованного. Но вот сказать что больше занимает время, само соединение или смена контекста - не могу сказать. Кстати и не только это занимает время при инициализации сессии. |
15 окт 12, 20:09 [13322687] Ответить | Цитировать Сообщить модератору |
пообедитель
Guest |
смысл в чем? вообще в чем смысл? была толпа логинов равная количеству пользователей, а теперь мы делаем "единую точку входа" и... толпу логинов равную количеству пользователей для execute as, yeaaah!!! победа. + шикарнейшая дырень для "тупо вызванного без execute as" |
||
15 окт 12, 20:42 [13322775] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
Лимоны пользователей. Хм. Блин. Точно. Если пользователей не много, то есть ли вообще смысл экономить на пулах соединений. Если пользователей много, то не будет ли накладным это обрабатывать. Банально их список забьёт оперативу скуля? В подходе Context_info проверка сконцентрировано на ролях, поэтому их (проверок) самих по себе не много.
Можно урегулировать права к скулю App ролью, к примеру. |
||||
15 окт 12, 22:39 [13323064] Ответить | Цитировать Сообщить модератору |
sp Member Откуда: Сообщений: 3947 |
туповызванного не может быть - потому что умнопридуманная хрень направит все в одну sp :) |
||
15 окт 12, 23:07 [13323137] Ответить | Цитировать Сообщить модератору |
sp Member Откуда: Сообщений: 3947 |
все остальные проблемы решаются по мере их возникновения - сейчас пока одна большая проблема: либо юзеры "виртуальные" и SQL ничем не рулит в смысле прав доступа или наоборот - ЫЙД рулит доступом а в контексте указывать юзера - дилема однако! :) |
||
15 окт 12, 23:10 [13323151] Ответить | Цитировать Сообщить модератору |
sp Member Откуда: Сообщений: 3947 |
пообедитель, смысл в том - чтобы из любого приложения вплоть до Excel можно было бы не иметь головняка что кому разрешено или не разрешено - если есть юзеры SQL - этим можно рулить - если юзеры "виртуальные" тогда - ой ! :)) шо я скажу Экселю?? |
15 окт 12, 23:31 [13323220] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
Если пользователей лимон, но активных мало, то можно спул под-настроить. Если много или активно обновляются, то конечно проблема спамить коннектами. ASP.NET - ещё ничего не значит. Есть ещё один метод. Хитрый. Коннект завязан не на пользователе, а на комбинации ролей. Если их не много, то и комбинаций мало и не все комбинации нужны, то сойдёт. |
||
15 окт 12, 23:43 [13323254] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
Головняк зависит от автоматизации. Можно и пользователей иметь, те кто к Excel и виртуальные. Это как вы будете олицетворять ваших логических (dbo.Users) на скулевские. Т.е. не вижу тут проблем особых.
|
||
15 окт 12, 23:50 [13323283] Ответить | Цитировать Сообщить модератору |
DeColo®es Member Откуда: Москва Сообщений: 5503 Блог |
Вот я бы не стал делать 3-х звенку с возможностью прямого подключения к базе. Потому, что если все разруливать на уровне БД, нужда в 3-м слое элементарно отпадает вместе со всеми его возможностями. Ну либо дублировать весь функционал в ХД и app-сервере. Но это удовольствие то еще - все, что элементарно делается на TSQL - это куча строк (обычно неоптимального и неэффективного) кода на каком-нибудь C# и наоборот. Попробуйте написать алгоритм сложного соединения 10-ка справочников на процедурном языке или сделать быструю циклическую обработку в TSQL.... |
16 окт 12, 00:02 [13323328] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
DeColo®es, а не преувеличиваете ли вы проблему? Ибо задач много и ХЗ какая у ТС. App сервер это не только проверка прав/олицетворение. Это решатель задач, не свойственные БД, и лёгкий цикл разработки/доработки. Отказываться из-за такой ерунды не вижу смысла. И в крайности тоже нет смысла впадать - только Entity Framework - vs - вся логика на скуле (тока процедуры). |
16 окт 12, 00:18 [13323401] Ответить | Цитировать Сообщить модератору |
sp Member Откуда: Сообщений: 3947 |
а если юзер всеже нужен (а в 99% он нужен) - откуда его брать будем? |
||||
16 окт 12, 00:37 [13323455] Ответить | Цитировать Сообщить модератору |
sp Member Откуда: Сообщений: 3947 |
Среднее звено должно быть только передастом и трансформатором - остальное зло! А то потом под Excel все допиливать, а потом еще под чтото опять - точить и так до скончания жизни! Каждому свое - бизнес-логика и управление данными - в Скуль отображалка данных и их ввод- любая держиморда от Экселя до блокнота! |
||
16 окт 12, 00:40 [13323468] Ответить | Цитировать Сообщить модератору |
DeColo®es Member Откуда: Москва Сообщений: 5503 Блог |
Изменить базу (подменить ХП, изменить структуру, перелить данные) - это просто запустить скрипт "стандартным" для БД способом. А вот изменить логику работы AppServer - это фактически менять сам AppServer А вот про несвойственные для БД задачи - это однозначно на уровне AS решается проще. По крайней мере, если более-менее грамотно спроектировать приложение, то даже самый тормознутый код на AS будет легко масштабироваться. Просто воткнул еще десяток машин за балансировщиком. А попробуйте-ка отмасштабировать БД... Кстати, из всех задач, которые лично мне доводилось решать, только одну было нереально "выдернуть" из базы данных - это пересчет остатков по счетам - там "все" должно делаться строго в транзакции. А вот все остальное... Ну потратим мы 0,1 секунду лишнюю на подготовку данных на AS, которые нельзя закоммитить в БД из-за чего-то вроде неожиданно возникшего красного сальдо... Ну так и при работе в БД делать всю работу в единой транзакции - не всегда лучшее решение и пользователь все равно знает, что в последний момент может получить отказ. В общем, я к тому, что если уж есть сервер приложений - его нужно загрузить по-максимуму, оставив в БД только то, для чего она и создавалась - транзакции, фильтрации/группировки/агрегаты и т.д.2622 |
||
16 окт 12, 00:48 [13323486] Ответить | Цитировать Сообщить модератору |
DeColo®es Member Откуда: Москва Сообщений: 5503 Блог |
И я тоже
|
||||
16 окт 12, 00:53 [13323506] Ответить | Цитировать Сообщить модератору |
Mind Member Откуда: Лучший город на Земле Сообщений: 2322 |
|
||
16 окт 12, 04:14 [13323821] Ответить | Цитировать Сообщить модератору |
sp Member Откуда: Сообщений: 3947 |
как накой? вот ISS с ASP.NET и есть среднее звено - работает передастом-транслятором данных: - от клиента в sp-шки - из sp-шек клиенту в удобоваримом виде :) |
||||
16 окт 12, 06:24 [13323853] Ответить | Цитировать Сообщить модератору |
sp Member Откуда: Сообщений: 3947 |
Приведите хоть один довод за то чтобы тратить время на разработку middleware и разрыв логики бизнес-процессов (или ее дублирование в БД и на среднем звене)
А что тут такого? Вы не видели не разу приложений в Excel, работающих с БД - посмотрите - их там есть! :)) И кто мешает работать с Блокнотом - чем не интерфейс для отображения и редактирования данных??? |
||||
16 окт 12, 06:27 [13323856] Ответить | Цитировать Сообщить модератору |
доброе_тепло
Guest |
|
||||
16 окт 12, 09:48 [13324359] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
![]()
Конечно тоже в основном похожее делал, но такой категоричностью не болею ... в этой области ... так явно. ![]() Если посмотреть внимательно на эту прослойку, то оказывается в сумме она не мало делает. Даже если вся бизнес логика в БД втюхана. Только чем больше требований тем больше App на себя берёт. А в вебе вообще почти всё. Особенно когда языки становятся более выразительными. Не надо путать желание и стремление писать на декларативном и монолитном языке с реалиями. БД вон пытаются масштабировать. Можно наворачивать всякие интерфейсы и т.д. в 22 век. Но в итоге это уже не СУБД, а декларативная монолитная среда разработки, где границы между БД и AS и Клиентом будут размыты, пусть компилятор/интерпретатор сам решает где что работает. Только тут не SQL ни ООП не будет. Мечтательно: Декларативные интерфейсы ...
|
||||||
16 окт 12, 12:20 [13325636] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
Блин. сказал же - если есть: только роли, их мало ... можно и комбинации. Context_Info Передавать пользователя параметром. Или вы хотите из-за одной бесполезной через *опу написанный фишки внедрять мега-комбайн? |
||
16 окт 12, 12:31 [13325725] Ответить | Цитировать Сообщить модератору |
sp Member Откуда: Сообщений: 3947 |
Вот пытаюсь изобрести хоть одну хреновину для коей мне нужен был бы непременно апп-сервер - и не могу придумать! Приведите хоть один довод, чтобы стоило тратить время и силы на распыление логики по звеньям!? |
||||
16 окт 12, 13:55 [13326474] Ответить | Цитировать Сообщить модератору |
Crimean Member Откуда: Сообщений: 13148 |
без отказа от прямой работы с базой - 50/50 с отказом - начальных трудозатрат может быть больше зато "после", особенно при широком спектре задач интеграции - может быть интереснее средний слой может снять кучу условностей с той же безопасностью но при компромиссном подходе (когда останется и прямая работа с базой) может только мешать |
||
16 окт 12, 14:01 [13326540] Ответить | Цитировать Сообщить модератору |
DeColo®es Member Откуда: Москва Сообщений: 5503 Блог |
|
||||
16 окт 12, 14:38 [13326931] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |