Здравствуйте, Ночной Смотрящий, Вы писали:

НС>При чем тут синхронизация? Я переименовал поле в БД. Теперь мне надо переименовать это поле во всем прикладном коде.

Во всем прикладном коде так и переименовывается решарпером.

НС>В случае LINQ типы БД интегрированы в язык, поэтому работает самый обыкновенный рефакторинг. А вот в случае склейки строк или твоих экзерсисов на тему query builder все намного печальнее.

V>>А проблемы таких велосипедов мы тоже прекрасно знаем, и? На тот момент это было лучшее решение из всевозможных виденных на дотнете.
НС>В контексте топика никого тот момент не волнует, к чему ты его приплел?

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


НС>Сейчас есть expression tree, поэтому всю это кривоватую хрень можно смело выкинуть.

В том синтаксисе что ты показал — достижения не большие, прямо скажем.


НС>Ну вот а обычных я имел возможность наблюдать в дикой природе с соответствующими выводами.

Я тоже говнокодеров видел много, и?


V>>В банках и на биржах тебе рассмеются в лицо, если ты им предложишь что-то на дотнете-Linq
НС>Ты просто не в теме.

Я как раз давно и плотно в теме.

НС>IT, кстати, в отличие от тебя, последнее время в основном в финансово-банковской сфере работает.

Ну я прекрасно знаю, что именно в этой "сфере" делают на дотнете. Это околосфера возле сферы. ))

НС>И вот, такое дело, его наблюдения почему то полностью совпадают с моими.

Пока не увижу в новостях, что где-то вышел движок биржи на Linq или банковский оп-день — это всё сказки про белого бычка. Оттуда уже даже Джава вымывается с большой скоростью.


V>>, для чего-то, где нужна хоть какая-то надежность.
НС>О, программисты АЭС. Давненько их тут не появлялось.

Для движка биржи и банковского оп-дня нужна не меньшая надежность. Предположи, как построена технологически та же NASDAQ? CME? SGX?


V>>Запросы на много страниц как раз неплохо сокращаются вьюхами и табличными ф-ями, содержащими самые популярные для базы наборы джоинов.
НС>Затрахаешься на каждый запрос уникальные функции плодить.

Ты упорно не понимаешь о чем речь... а говоришь, что в теме.

V>> Они почти всегда одни и те же, эти основные джоины.
НС>Что ты в джойны все упираешься? Есть много разных конструкций, раздувающих запросы до неизведанных высот.

Даже в них те же самые повторяющиеся конструкции.

V>>Ну ты хоть понимаешь, кривизну какого уровня ты описываешь?
НС>Это вот такая реальность и такие DBA.

Бред. Ты показал просто плохого программиста. Хороший админ базы не есть хороший программист базы. Я же о последних, ес-но. Не зря даже в настройках уровня доступа это разные роли.


НС>А зачем прямо в тексте то? Параметры отменили что ли?

Ну так это временная хранимка.

Здравствуйте, gandjustas, Вы писали:

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

В данном натянутом примере — да. А реальный? Ну и не забываем, что "хранимки" — они тоже не с секторами диска работают, им тоже нужен доступ к записям, которые тоже физически вытаскиваются в операбельную структуру. Итак?...

Здравствуйте, btn1, Вы писали:

B>Здравствуйте, gandjustas, Вы писали:

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

B>В данном натянутом примере — да. А реальный? Ну и не забываем, что "хранимки" — они тоже не с секторами диска работают, им тоже нужен доступ к записям, которые тоже физически вытаскиваются в операбельную структуру. Итак?...
Чтобы не путаться:
1) Хранимки — набор sql операторов, которые выполняются на стороне СУБД без раундтрипов с клиентом
2) В принципе ничего не мешает отправить такой же набор операторов одним батчем с клиента на сервер
3) Хранимки лишь обеспечивают инкапсуляцию логики в базе

Поэтому перефразирую вопрос — "может вообще всю логику выполнять в приложении, а не в SQL?"

Однозначно нельзя. Даже если отбросить вопросы надежности хранения, особенно при конкурентной работе.
Выполнение SQL запроса оптимизируется с точки зрения обращения к диску (который является самой медленной частью любой системы). Например для получения тех же 10 последних заказов текущего пользователя СУБД даже не будет поднимать с диска все записи о заказах (которых могут быть миллионы). Индексы в СУБД позволяют считать с диска ровно столько, сколько необходимо для получения результатов запроса, причем в уже отсортированном виде.

Здравствуйте, btn1, Вы писали:

B>Я опасаюсь вторых священных войн, но всё равно интересно: зачем вообще в 21 веке используют "хранимки"? Одни тут прогресс двигают, квадратики рисуют, MVC, MVVM и т.п., а другие шмякают эти "процедуры 20 века" и в ус не дуют! Что там такого "волшебного" делается, чего нельзя сделать на серверной стороне обычным кодом внутри "модели"?
Если отбросить инерцию мышления и карго культы, то хранимки — это способ превратить SQL сервер в application server с RPC-протоколом. Это может быть полезно, например, в случаях наличия большого количества клиентов (веб-приложение, даже сложное и с большой нагрузкой — это один клиент).

Здравствуйте, Sinclair, Вы писали:

S>[/sql]
S>1.а. Используем процедурное расширение SQL:
S>

S>if (@shipDateFrom is null)
S>begin
S>  if (@shipDateTo is null)
S>    select * from orders
S>  else
S>    select * from orders where ShippedDate <= @shipDateTo
S>end
S>else begin
S>  if (@shipDateTo is null)
S>    select * from orders where ShippedDate >= @shipDateFrom
S>  else
S>    select * from orders where ShippedDate >= @shipDateFrom and ShippedDate <= @shipDateTo
S>end
S>

Процедура со сложностью поддержки аргументов n^2 имени маляр Шлемиэля.

Здравствуйте, vdimas, Вы писали:


НС>>А нафига мне твои теоретические идеальные DBA, если и я и IT в реальных ситуациях видим совсем другое?

V>Провайдеры пока кривые и косые
В чем это выражается?

V>низлежащее ADO тоже не блещет. Например, я лично баг отправлял в MS когда-то по парсеру MS SQL потока. Исправили потом в одном из SP.
Я видел баг в .NET 1.1, говорят был еще баг в .NET 2.0. Если что, текущая версия .NET 4.5.1. про баги не слышал.

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

V>Даже этот сайт, несложное, по-сути, приложение (это без попыток наезда) периодически выдаёт ошибки базы.
Ты про дедлоки? Как это связано с Linq и ADO.NET?

V>Блин, я такого даже вообразить не мог, когда пользовался ODBC или OLE DB, там надежность была железобетонная.
База, как и любой внешний сервис может отвалится, не предупредив приложение. Все возможные технологии отказоустойчивости все равно дают даунтайм на время failover. И дело вовсе не в ODBC или ADO.NET.
Но даже если база не падает, то твой запрос, даже самый безобидный, может отвалиться по куче причин. Начиная от банального дедлока, заканчивая происками resource governor.

V>Это же БАЗА, ёптить! )))
Ты слишком мало работал с промышленными СУБД, если так говоришь.

V>Запросы на много страниц как раз неплохо сокращаются вьюхами и табличными ф-ями, содержащими самые популярные для базы наборы джоинов. Они почти всегда одни и те же, эти основные джоины.
Дело не во вьюхах и джоинах, а в предикатах и проекциях. Это две самые изменяемые части запросов.
Для примера тот же интернет-магазин средней руки, в нем есть таблица товаров из котром можно выбирать:
1) По бренду
2) По наличию
3) По гарантии

А еще можно сортировать по:
1) Цене
2) Названию

И еще надо постраничное разбиение не забыть.

Даже если ты сделаешь вьюху, то все равно надо поверх нее сгенерировать около 15 запросов. И это мы еще проекции не считали.

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


V>Вот я делаю выборку с итогом по некоему товару, скажем, из довольно большой таблицы движений, и каждый раз запрашиваю итоги по другому товару, будет ли тут кеширование запроса, если это не хранимка с параметром или табличная ф-ия, а прямо в тексте подаваемого запроса фигурирует новое числовое некое ID товара?
Что такое кеширование запроса? SQL Server кеширует планы, чтобы не перекомпилировать.

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

Здравствуйте, vdimas, Вы писали:

V>Пока не увижу в новостях, что где-то вышел движок биржи на Linq или банковский оп-день — это всё сказки про белого бычка.
А ты видишь в новостях про биржи на ODBC или опердни на ADO?
Работа с данными не самая важная часть приложения, хотя зачастую и самая ресурсоемкая. А Linq вообще не более чем генератор запросов, от которого можно в будущем отказаться, если активная разработка уже не ведется (как сделали в StackOverflow).
Но именно этот генератор запросов позволяет разрабатывать приложения с огромной скоростью, не нагружая DBA написанием селектов.

Здравствуйте, gandjustas, Вы писали:

G>Поэтому перефразирую вопрос — "может вообще всю логику выполнять в приложении, а не в SQL?"

G>Однозначно нельзя. Даже если отбросить вопросы надежности хранения, особенно при конкурентной работе.

Тут ничего отбрасывать и не нужно: сервис типа СУБД и создан для того, чтобы всё было надёжно — ему пофиг, откуда пришёл запрос.

G>Выполнение SQL запроса оптимизируется с точки зрения обращения к диску (который является самой медленной частью любой системы).

Разве для запроса к данным есть разница, пришёл он от хранимки или от внешнего клиента??

Пока что всё отличие хранимки от ВК(внеш.клиент) — отсутствие у ВК процедурной части. Напомню: обе сущности сидят на стороне сервера.
Попробую схематично изобразить моё представление:

Внешний клиент:

Клиент -> носитель, передающий SQL запрос (API сервера) -> обработчик запроса внутри СУБД (со всеми кэшами, оптимизациями и т.п.)

Хранимка:

Исходник (PL/SQL, T-SQL) -> некий процедурный псевдокод(ПП). Сервер исполняет этот ПП (в меру скорости своей виртуальной машины) -> ПП делает промежуточные SQL обращения к данным -> обработчик запроса внутри СУБД (со всеми кэшами, оптимизациями и т.п.)
----------------------------------------------------------
Итого, даже если допустить разницу в представлении записи для ПП и для ВК(хотя какой смысл это делать?), я не думаю, что это сильно влияет на производительность. ПП — он тоже ведь существует не в абстрактном ЦПУ с бесконечной производительностью — это просто МОДУЛЬ, внешний по отн. к внутренним механизмам СУБД и исполняющийся на том же процессоре, что и ВК (только ещё посмотреть, чей код быстрее — скомпилированного ВК или ПП!).

Получается, с ВК мы имеем всю мощь ЯВУ со всем мыслимыми библиотеками, а с ПП — убогий набор языковых средств, который удосужились сделать разработчики СУБД. Поэтому опять подымается вопрос: накой нам хранимки? С ними мы:
1. Имеем геморой с подключением к проекту дополнительного языка (много ли найдётся спецов, досконально знающих C# и при этом так же хорошо владеющих PL/SQL?)
2. Хуже того: создавая хранимки, мы резко всаживаем в зад крюк проприетарщины — попробуй, смени MS SQL на Oracle! И не просто "перепиши все хранимки", а ещё правильно это сделай (см. п.1 про спецов).
3. ВК — это ещё и широчайшая свобода технологий: хочешь — авторизуйся через AD, хочешь — прикрути защиту через HASP, не понравилось — есть ещё сотни библиотек, которых не существует в СУБД, но которые ты можешь юзать в ВК.
4. Уже упомянутый геморой с рефакторингом: есть море утилит, вытаскивающих структуру БД и синхронизирующую с текущим набором классов. Но чтобы сделать то же самое с хранимками — это уже двойной гемор для самой синхронизации и ещё n-кратный, если надо синхронизировать другой тип СУБД.
5. Теряем в гибкости. Переписать/перекомпоновать свой сервис под новые требования — это несколько часов в студии, весело жонглируя модулями. Делать то же самое в хранимках — может оказаться вообще невозможным! (см. п. 3) Не говоря про "никакие" средства рефакторинга на стороне СУБД.

В результате народ продолжает писать хранимки, свято веря в древние легенды о производительности, хотя никаких замеров даже не пытаются сделать. И ДАЖЕ если мы теряем сколько-то процентов на ВК, это с лихвой окупается гибкостью самого решения.

Здравствуйте, Sinclair, Вы писали:

S>Если отбросить инерцию мышления и карго культы, то хранимки — это способ превратить SQL сервер в application server с RPC-протоколом.

+1!!

S> Это может быть полезно, например, в случаях наличия большого количества клиентов (веб-приложение, даже сложное и с большой нагрузкой — это один клиент).

Ну так это уже вопрос устройства веб-сервера! (и даже при самом убогом веб-сервере можно сделать целую ферму таких серверочков + балансировка)

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

Но как бы то ни было, тут всё равно не видно, за счёт чего хранимка может выигрывать: фактически, хранимка — это тот же процедурный код вокруг данных: как только данные получены, всё будет зависеть только от скорости работы этого процедурного кода, что хранимка, что модуль сервера приложений.

Здравствуйте, vdimas, Вы писали:

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

Можно я рассмеюсь в лицо тебе сидя в банке и используя дотнет-Linq уже много лет? Спасибо!

V>Я почти сразу столкнулся с тем, что под нагрузкой ADO.Net периодически глюкало еще с самых первых версий. Блин, я такого даже вообразить не мог, когда пользовался ODBC или OLE DB, там надежность была железобетонная. Это же БАЗА, ёптить! )))

За последние несколько лет была только одна неразрешимая проблема с надёжностью ADO.NET. Задача, которая крутилась месяцами (Windows Service) иногда вылетала к понедельнику. Препарирование проблемы показало, что админы по восткресеньям жестко перегружали сервер БД. БД — Sybase — это важно. При этом при обращении к этой БД в такой ситуации возникало исключение в нативной части Sybase провайдера. После примерно пары десятков таких исключений Sybase провайдер сшибал нафиг .NET runtime. Отловить и восстановиться после такого исключения невозможно. Пришлось делать восстановление работоспособности приложения средствами самой Winndows. Через пару лет переход на новую версию Sybase драйвера проблема решилась сама собой.

Итого имеем. Ненадёжность ADO.NET была обусловлена наличием нативного кода в и без того глючном драйвере Sybase, написанного криворукими китайцами.

Здравствуйте, IT, Вы писали:

IT>Итого имеем. Ненадёжность ADO.NET была обусловлена наличием нативного кода в и без того глючном драйвере Sybase, написанного криворукими китайцами.

Даже не так.

Ненадёжность ADO.NET была обусловлена наличием нативного кода в и без того глючном драйвере Sybase, написанного криворукими китайцами и необходимостью еженедельной перегрузки DBA-ями "супернадёжной" и одной из наиболее распространённой БД в банках, не имеющей к .NET никакого отношения.

Здравствуйте, btn1, Вы писали:

B>Попробую схематично изобразить моё представление:

B>Внешний клиент:

B>Клиент -> носитель, передающий SQL запрос (API сервера) -> обработчик запроса внутри СУБД (со всеми кэшами, оптимизациями и т.п.)

B>Хранимка:

B>Исходник (PL/SQL, T-SQL) -> некий процедурный псевдокод(ПП). Сервер исполняет этот ПП (в меру скорости своей виртуальной машины) -> ПП делает промежуточные SQL обращения к данным -> обработчик запроса внутри СУБД (со всеми кэшами, оптимизациями и т.п.)
B>----------------------------------------------------------
B>Итого, даже если допустить разницу в представлении записи для ПП и для ВК(хотя какой смысл это делать?), я не думаю, что это сильно влияет на производительность. ПП — он тоже ведь существует не в абстрактном ЦПУ с бесконечной производительностью — это просто МОДУЛЬ, внешний по отн. к внутренним механизмам СУБД и исполняющийся на том же процессоре, что и ВК (только ещё посмотреть, чей код быстрее — скомпилированного ВК или ПП!).
Промежуточный код, называемый "планом запроса" используется как для хранимок, так и для запросов от приложения (adhoc запросов). Планы запроса однозначно быстрее, потому что оптимизируют чтение с диска. Приложению для начала нужно все данные затянуть в память и с ними работать, а для СУБД это не требуется.


B>Получается, с ВК мы имеем всю мощь ЯВУ со всем мыслимыми библиотеками, а с ПП — убогий набор языковых средств, который удосужились сделать разработчики СУБД. Поэтому опять подымается вопрос: накой нам хранимки? С ними мы:
B>1. Имеем геморой с подключением к проекту дополнительного языка (много ли найдётся спецов, досконально знающих C# и при этом так же хорошо владеющих PL/SQL?)
B>2. Хуже того: создавая хранимки, мы резко всаживаем в зад крюк проприетарщины — попробуй, смени MS SQL на Oracle! И не просто "перепиши все хранимки", а ещё правильно это сделай (см. п.1 про спецов).
B>3. ВК — это ещё и широчайшая свобода технологий: хочешь — авторизуйся через AD, хочешь — прикрути защиту через HASP, не понравилось — есть ещё сотни библиотек, которых не существует в СУБД, но которые ты можешь юзать в ВК.
B>4. Уже упомянутый геморой с рефакторингом: есть море утилит, вытаскивающих структуру БД и синхронизирующую с текущим набором классов. Но чтобы сделать то же самое с хранимками — это уже двойной гемор для самой синхронизации и ещё n-кратный, если надо синхронизировать другой тип СУБД.
B>5. Теряем в гибкости. Переписать/перекомпоновать свой сервис под новые требования — это несколько часов в студии, весело жонглируя модулями. Делать то же самое в хранимках — может оказаться вообще невозможным! (см. п. 3) Не говоря про "никакие" средства рефакторинга на стороне СУБД.

B>В результате народ продолжает писать хранимки, свято веря в древние легенды о производительности, хотя никаких замеров даже не пытаются сделать. И ДАЖЕ если мы теряем сколько-то процентов на ВК, это с лихвой окупается гибкостью самого решения.

Вопрос не корректно поставлен. Как в хранимке, так и в клиентском приложении надо писать одинаковые запросы, которые проходят через абсолютно одинаковый пайплайн исполнения. Иначе не видать производительности.
1) Геморрой подключения нового яызка остается, только если не пользуешься Linq в C#, но даже он не освобождает от необходимости понимания какие запросы летят в базу.
2) Проблема со сменой СУБД не менее актуальна, опять-таки Linq поможет сгладить проблему, но устранить её.
3) Наличие хранимок в базе не делает ненужным клиентское приложение.
4) Неактуальная проблема на сегодня. Те же утилиты могут генерить методы по хранимкам. В F# такое реализовано в виде TypeProvider.
5) Это следствие п1


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

Но при наличии Linq-провайдеров в БД преимущества сильно на стороне написания Linq запросов, которые трансформируются в SQL запросы.

Здравствуйте, btn1, Вы писали:

B>Здравствуйте, Sinclair, Вы писали:

S>>Если отбросить инерцию мышления и карго культы, то хранимки — это способ превратить SQL сервер в application server с RPC-протоколом.

B>+1!!

S>> Это может быть полезно, например, в случаях наличия большого количества клиентов (веб-приложение, даже сложное и с большой нагрузкой — это один клиент).

B>Ну так это уже вопрос устройства веб-сервера! (и даже при самом убогом веб-сервере можно сделать целую ферму таких серверочков + балансировка)

B>Тут уже нужно бенчмаркать: может статься так, что серверу приложений выгоднее (временно) выстроить очередь, но быстро её обработать за счёт отсутствия чужих локов на таблице, чем генерить десять разных клиентов БД, каждый из которых будет ждать своего обслуживания, но зато они "как бы сразу" приняты к обработке.
То есть ты считаешь, что очередь в приложении может быть выгоднее очереди внутри СУБД? Гранулярность блокировок в СУБД — одна запись, соответственно запросы, получающие две разные записи не будут выстраиваться в очередь. А на уровне приложения ты сможешь сделать гранулярность на уровне таблиц. Теоретически можно и с ключами отдельных записей делать блокировки, но тогда сразу убьешься об дедлоки.

Здравствуйте, gandjustas, Вы писали:

G>Планы запроса однозначно быстрее, потому что оптимизируют чтение с диска. Приложению для начала нужно все данные затянуть в память и с ними работать, а для СУБД это не требуется.

Разве? Если я делаю выборку на 1М записей, я даже получаю их порциями, а обрабатываю вообще по одной. Неужто сервер не имеет оптимизаций на случай "клиент попросил много записей, но их не обязательно отсылать все сразу"?

G>Вопрос не корректно поставлен. Как в хранимке, так и в клиентском приложении надо писать одинаковые запросы, которые проходят через абсолютно одинаковый пайплайн исполнения. Иначе не видать производительности.

Ты говоришь очевидное и мною подразумеваемое условие. Вопрос вообще не про LINQ, он ставится так: Необходимо сделать низкоуровневую работу на уровне записей БД, чтобы освободить бизнес-логику от SQL-специфики.
Два варианта: пишем непереносимые хранимки на языке, специфичном для данной СУБД (и даже для версии СУБД), второй вариант — на сервере приложений, внутри "классов-моделей", пишем на обычном ЯВУ команды, делая все те же действия/запросы, что и в хранимке. Ответ по-моему очевиден: классы-модели.


G>1) Геморрой подключения нового яызка остается, только если не пользуешься Linq в C#, но даже он не освобождает от необходимости понимания какие запросы летят в базу.

Не путай "подключить SQL к C#" с "подключить PL/SQL к C#"! Если SQL мало-мальски стандартизован, то проприетарные недоязыки уж точно пятое колесо!

G>2) Проблема со сменой СУБД не менее актуальна, опять-таки Linq поможет сгладить проблему, но устранить её.

Смена БД, имеющей хранимки, НА ПОРЯДОК сложнее БД с чисто таблицами. Я утверждаю только это, ты с этим согласен?

G>В харнимках чуть сложнее делать данимаческие запросы, но меньше раундтрипов до клиента и проще хинтами запинать запросы.

Согласен. Но я предполагаю, что сервер не настолько туп и не настолько проседает в производительности, чтобы скатываться к хранимкам — далеко не все базы требуют производительности биллинговых систем.

G> Кроме того при изменении запроса в хранимке не требуется редеплой приложений.

А что, "изменение хранимки" у нас бесплатное?? Ровно такой же редеплой, только вместо перезаписи DLLек — загляд и залаз в базу. Точно такая же опасная операция.

G>Но при наличии Linq-провайдеров в БД преимущества сильно на стороне написания Linq запросов, которые трансформируются в SQL запросы.

Не про LINQ речь, но я тебя понял. Ты согласен с тем, что на сегодня нет никаких серьёзных причин писать хранимки?

Здравствуйте, gandjustas, Вы писали:

G>То есть ты считаешь, что очередь в приложении может быть выгоднее очереди внутри СУБД? Гранулярность блокировок в СУБД — одна запись

Если я пишу в таблицу море записей, я могу вообще со всей очереди собрать данные на запись и заструячить одним пакетом — клиент-то один! Если же пишут разные клиенты БД, для каждого из них серверу придётся аккуратно встать в режим "на, записывай!", синхронизируя внутреннее состояние. Разные клиенты — это как враги, сервер должен позаботиться о том, чтобы они не передрались за ресурсы Единый клиент имеет больше информации о логике операций.

Да и не об этом речь, а о хранимках — очень сомнительно, что у них есть какое-то кратное преимущество при обслуживании большого количества запросов перед кодом на сервере приложений.

Здравствуйте, btn1, Вы писали:

B>Здравствуйте, gandjustas, Вы писали:

G>>Планы запроса однозначно быстрее, потому что оптимизируют чтение с диска. Приложению для начала нужно все данные затянуть в память и с ними работать, а для СУБД это не требуется.

B>Разве? Если я делаю выборку на 1М записей, я даже получаю их порциями, а обрабатываю вообще по одной. Неужто сервер не имеет оптимизаций на случай "клиент попросил много записей, но их не обязательно отсылать все сразу"?
Никто не делает выборки на миллион записей. Делают выборки типа 100 последних заказов клиента с каким то id. SQL достанет записи из индекса, прочитав менее 10 страниц (8 килобайт).
Предположим ты захотел сделать это на стороне приложения, тогда ты должен прочитать все заказы, которых миллионы, то есть поднять с диска около около гб данных, прокачать по сети, пробежаться по всем, выбрать которые нужны и отсортировать их по убыванию, выбрать первые 100 и показать.
Учитывая, что таких запросов в секунду может приходить много, и по разным клиентам посчитай какой объем данных надо будет обрабатывать на каждый запрос.
А ведь это примитивный запрос.


G>>1) Геморрой подключения нового яызка остается, только если не пользуешься Linq в C#, но даже он не освобождает от необходимости понимания какие запросы летят в базу.

B>Не путай "подключить SQL к C#" с "подключить PL/SQL к C#"! Если SQL мало-мальски стандартизован, то проприетарные недоязыки уж точно пятое колесо!
У каждой субд свой диалект.

G>>2) Проблема со сменой СУБД не менее актуальна, опять-таки Linq поможет сгладить проблему, но устранить её.

B>Смена БД, имеющей хранимки, НА ПОРЯДОК сложнее БД с чисто таблицами. Я утверждаю только это, ты с этим согласен?
Нет, ибо зависит от запросов. Например если динамическая генерация запросов на TSQL написана на c#, то ей гораздо сложнее портировать на оракл, чем просто переписать хранимки.

G>> Кроме того при изменении запроса в хранимке не требуется редеплой приложений.

B>А что, "изменение хранимки" у нас бесплатное?? Ровно такой же редеплой, только вместо перезаписи DLLек — загляд и залаз в базу. Точно такая же опасная операция.
Работа субд не останавливается при этом. А приложение таки надо останавливать.

G>>Но при наличии Linq-провайдеров в БД преимущества сильно на стороне написания Linq запросов, которые трансформируются в SQL запросы.
B>Не про LINQ речь, но я тебя понял. Ты согласен с тем, что на сегодня нет никаких серьёзных причин писать хранимки?
По сравнению с чем? Для сценария клиент-серверных приложений я бы выбрал инкапсуляцию запросов в базе — представления, функции, триггеры, хранимки. В остальных случаях — linq.

Здравствуйте, btn1, Вы писали:

B>Здравствуйте, gandjustas, Вы писали:

G>>То есть ты считаешь, что очередь в приложении может быть выгоднее очереди внутри СУБД? Гранулярность блокировок в СУБД — одна запись

B>Если я пишу в таблицу море записей, я могу вообще со всей очереди собрать данные на запись и заструячить одним пакетом — клиент-то один! Если же пишут разные клиенты БД, для каждого из них серверу придётся аккуратно встать в режим "на, записывай!", синхронизируя внутреннее состояние. Разные клиенты — это как враги, сервер должен позаботиться о том, чтобы они не передрались за ресурсы Единый клиент имеет больше информации о логике операций.
Может быть и выгоднее, но при чем блокировки? И что делать если у тебя в пакет попали конфликтующие изменения. Один пользователь например хочет увеличить значение поля на единицу, а другой уменьшить.

B>Да и не об этом речь, а о хранимках — очень сомнительно, что у них есть какое-то кратное преимущество при обслуживании большого количества запросов перед кодом на сервере приложений.
Это смотря как писать.

Здравствуйте, btn1, Вы писали:

B>Ну так это уже вопрос устройства веб-сервера! (и даже при самом убогом веб-сервере можно сделать целую ферму таких серверочков + балансировка)
Нет. С точки зрения версионности, вся ферма — это один клиент. Т.е. у нас гарантия непротиворечивости бизнес-логики обеспечивается единым кодом.
Проблемы начинаются тогда, когда у вас в одну и ту же БД одновременно ходят клиенты разных версий или типов.
Тогда единственный способ ограничить их самодеятельность и избежать расхождения логики — гонять их через сервер приложений. Т.е. — или трёхзвенка (которая с точки зрения СУБД является сведением к случаю одного клиента), или хранимки.

B>Но как бы то ни было, тут всё равно не видно, за счёт чего хранимка может выигрывать: фактически, хранимка — это тот же процедурный код вокруг данных: как только данные получены, всё будет зависеть только от скорости работы этого процедурного кода, что хранимка, что модуль сервера приложений.
Хранимка выигрывает не в перформансе, а в стабильности — нет риска, что какой-то багливый клиент снимет деньги со счёта A и забудет положить на счёт Б. Наружу вместо таблиц выставляются RPC-style процедуры; все изменения в логике этих процедур делаются централизованно.

Здравствуйте, gandjustas, Вы писали:

B>>А что, "изменение хранимки" у нас бесплатное?? Ровно такой же редеплой, только вместо перезаписи DLLек — загляд и залаз в базу. Точно такая же опасная операция.
G>Работа субд не останавливается при этом. А приложение таки надо останавливать.
Дело не только в остановке работы, а в количестве мест, где меняются dll-ки.
Хранимка существует ровно в одном экземпляре; весь DDL при развёртывании можно выполнить внутри одной транзакции, и обеспечить консистентную атомарную замену всей логики.
Если с базой работает 1500 копий клиентов из 30 географических мест, то обеспечить их согласованный апгрейд — та ещё логистическая задача. При наличии хранимок, максимум, что получит устаревший клиент — SQL Server Error при попытке вызова хранимки не с теми аргументами (это если изменилась сигнатура). При прямом доступе в базу и логике в "триггерах на клиенте" один "отставший" клиент может втихую поломать полбазы — например, плодя заказы в статусе, который больше никем не поддерживается.

R>Выскажите пожалуйста свои мнения!

ИМХО единственное что реально можно пользовать из EF это его LINQ провайдер, т.е. SELECT, пользоваться всем остальным крайне не рекомендовано.
Для меня EF это не ORM а замена для Linq 2 SQL.
Хотя в плане дизайна замена так себе.