View vs. Stored Procedure in SQL Server

[Strannik223]

Вы что то сразу ломитесь что то менять не имея арументированых представлений что именно тормозит (уверения админа в расчет не принимать!) А это плохая практика

Что бы отбросить от себя подозрения (или подтвердить) зайдите на сервер при помощи sql profiler и посмотрите что генерит типичный запрос

Те запросы которые занимают много чего нибудь (время IO, cpu) тяните в query analizer и смотрите план исполнения, после чего оптимизируйте их (если возможно)

Иногда случается что какой нибудь глупый запрос или код генерящий тысячи запросов убивает приложение, трасировщик позволяет это обнаружить

[Niky]

Если же таблицы содержат справочную информацию, которая не слишком часто меняется, то эти данные я бы вобще засунул в кэш (если у Вас classic ASP - в Application variable).

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

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

[Lightik]

Ну а если еще физически SQL Server и IIS на одном сервер то вы понимаете...

Я не думаю что данные от SQL Server в IIS идут через SSL

Вот выяснила таки наконец - физически они на разных серверах, и данные идут через SSL, поэтому и так долго, и каждый запрос столько времени выполняется. Черт. Так что самое гнусное предположение оказалось верным.

Знаете, какое решение в результате предложено? Сздать БД на том сервере, где SSL и веб-апликейшн, скинуть туда малоизменяемые данные, которые обычные пользователи сайта только читают (ну справочники всякие), sql таском каждое утро их обновлять, и на настоящую БД лазать только за динамическими данными. Тогда и запросов, требующих аутентикации будет немного.

Ответа про коннекшп пулинг я добиться не смогла - что-то вроде "неважно, есть он или нет, все равно никто менять это не будет."

Так шо выкручиваться придется вышеописанным образом. Ох, горе мне, горе...

[katit]

Вот выяснила таки наконец - физически они на разных серверах, и данные идут через SSL, поэтому и так долго, и каждый запрос столько времени выполняется. Черт. Так что самое гнусное предположение оказалось верным.

Понятно. Но зачем? Сервера в разных местах и досту по инету идет?
Или по сетке SSL гоняете?

[vovap]

Понятно. Но зачем? Сервера в разных местах и досту по инету идет?
Или по сетке SSL гоняете?

Скорее всего там между тем сервером, где SSL и SQL server стоит файреволл. Вот оно то и делает погоду. При этом да- как раз от числа обращений и зависит.

[vovap]

Вообще если бы кто из классиков по теории данных увидел бы этот топик - тотчас и помер бы. Что лучше - сторед процедуры или вью?
Сторед процедуры должны доставать данные из вью. Вот как должно быть.

[IA72]

Ну а если еще физически SQL Server и IIS на одном сервер то вы понимаете...

Я не думаю что данные от SQL Server в IIS идут через SSL

Вот выяснила таки наконец - физически они на разных серверах, и данные идут через SSL, поэтому и так долго, и каждый запрос столько времени выполняется. Черт. Так что самое гнусное предположение оказалось верным.

Знаете, какое решение в результате предложено? Сздать БД на том сервере, где SSL и веб-апликейшн, скинуть туда малоизменяемые данные, которые обычные пользователи сайта только читают (ну справочники всякие), sql таском каждое утро их обновлять, и на настоящую БД лазать только за динамическими данными. Тогда и запросов, требующих аутентикации будет немного.

Ответа про коннекшп пулинг я добиться не смогла - что-то вроде "неважно, есть он или нет, все равно никто менять это не будет."

Так шо выкручиваться придется вышеописанным образом. Ох, горе мне, горе...

Если вы пишете на ASP.NET, то там очень даже продвинутый и гибкий механизм кэширования, никакой "малоизменяемой" базы вам не понадобится.