AlexGПрограмма работает с БД.
Выбор встал между следующими подходами:
- писать хранимку для каждого набора данных отображаемого на клиенте;
- писать хранимку, возвращающая скопом данные одного типа (относящиеся к одной сущности?), а на клиенте отображать так, как уже надо.
Если то что нельзя сделать 1-им SQL запросом, кандидат на ХП.

Все остальное применения ХП - маразм (или "подводных камней" будет больше),imho.

Так_забежал_просто SQL Developer
Если то что нельзя сделать 1-им SQL запросом, кандидат на ХП.
Все остальное применения ХП - маразм (или "подводных камней" будет больше),imho.

Чтобы на каждый чих не переписывать клиента, многие запросы лучше хранить в базе. Код получается не намного сложнее.
Хм. А когда приходиться менять запросы то?
В 85-90% случаях при изменения запросов, меняеться и клиенты.

AlexGТ.е. у нас есть 3 связанных таблицы с данными. Вся информация содержит поля, например:
123456789
На клиенте нужно отобразить в гриде только эти:
2589
Остальные редактируются не в гриде а вдругих местах. Скажем, в дополнительных окнах.
Тогда и надо вытаскивать то что и нужно.
Сделайте VIEW на " есть 3 связанных таблицы с данными"
и вытаскивайте 1,3,4 или 8,9...
А при чем здесь ХП?

Так_забежал_просто SQL Developer
Хм. А когда приходиться менять запросы то?
В 85-90% случаях при изменения запросов, меняеться и клиенты.
Если усреднять по всем существующим ИС - да, где-то так :) В предельных случаях: если вся логика на клиенте, цифра достигает 100%; у трёхзвенки (в том числе если сервер приложений совмещён с сервером БД) - 0%.
У "трёхзвенки" такой же показатель, нет ни какой разницы.
Так как для app-server'a клиент будет web-server...
+ только в том что это делаеться в одном месте, а значит затраты на re-deployment будут очень низкими.

>> если сервер приложений совмещён с сервером БД
И это вообще непонятно что под этим скрываеться

AlexG SQL Developer AlexGТ.е. у нас есть 3 связанных таблицы с данными. Вся информация содержит поля, например:
123456789
На клиенте нужно отобразить в гриде только эти:
2589
Остальные редактируются не в гриде а вдругих местах. Скажем, в дополнительных окнах.
Тогда и надо вытаскивать то что и нужно.
Сделайте VIEW на " есть 3 связанных таблицы с данными"
и вытаскивайте 1,3,4 или 8,9...
А при чем здесь ХП?

Я опять не так сказал? Нам необходимы и другие поля, но в гриде показываются только указанные...
Ну тогда и вытаскиваете то ВСЕ что вам нужно.
Или если
>> Остальные редактируются не в гриде а вдругих местах.
>> Скажем, в дополнительных окнах
зачем тогда вытаскивать ВСЕ, а не только то что НУЖНО показать, а если ОСТАЛЬНЫЕ захотят редактировать, то и тогда вытащить то что нужно опять.

Типа
>>Сделайте VIEW на " есть 3 связанных таблицы с данными"
SELECT 1,3,4 FROM VIEW - это для drid
SELECT 8,9 FROM VIEW - это для другого окна

Так_забежал_просто
По-моему, в стандартной терминологии web-server - это и есть app-server. А клиент - это эксплорер. Как часто есть необходимость обновлять эксплорер?

web-server != app-server, это раз.
Далее, имелось ввиду, что для при изменении SQL'ов, а они будут меняться в app server'e, придеться менять и "то" что работает с этим app server'ом.

Клиент может быть и GUI приложение и общаться с app server'ом , не только через HTTP протокол.

Если у вас есть объект типа Customer
и у него метов getCustomersByCode(string code), и вы там поменяли внутри что-то, то тогда больше ничего ненатадо.
Но если было так getCustomersByCode(string code)
а надо так getCustomersByCode(int code)
то придеться менять еще и то где это вызываеться

P.S.
А надеюсь, вы неимеете ввиду там Apache+PHP (или типа того) как сервер приложений?

Так_забежал_просто SQL Developer
web-server != app-server, это раз.

Кто бы спорил. Веб-сервер <судорожно ищет значок "принадлежит"> апп-сервер. Или, точнее, из него можно сделать апп-сервер.
SQL Developer
Далее, имелось ввиду, что для при изменении SQL'ов, а они будут меняться в app server'e, придеться менять и "то" что работает с этим app server'ом.

Нет. Апп-сервер САМ сделает этот селект и вернёт на клиент РЕЗУЛЬТАТ, например, в HTML (можно и в другом формате). Этот HTML может содержать скрипты, например.
SQL Developer
P.S.
А надеюсь, вы неимеете ввиду там Apache+PHP (или типа того) как сервер приложений?
А чего в этом такого? Сервер приложений - это то, что содержит логику представления данных. PHP-скрипты, вроде, содержат логику представления данных? Или, если нет, зачем они нужны?
:-))))))
Ну да, кто-то и считает может быть и CGI и Perl, другими словами, тот кто возращает HMLT = это всегда апп-сервер :-))))))

Так_забежал_просто
Кто бы спорил. Веб-сервер <судорожно ищет значок "принадлежит"> апп-сервер. Или, точнее, из него можно сделать апп-сервер.

:-))))
Ага, это всеравно что сказать "а из Microsoft Office можно сделать Microsoft SQL Server"

Так_забежал_просто
...! Кто говорил про всегда? Вы невнимательны. Но сделать можно.

:-)))
Все-таки интересно что из чего собираетесь делать.
Все ОЧЕНЬ просто либо есть АПП-СЕРВЕР либо его нет.
И ни кто ни из чего не делает... ну если только разработчики этого АПП-СЕРВЕРа :-))

Так_забежал_просто
Ладно, всё. Продолжать можно только в том случае, если Вы дадите чёткое определение апп-сервера, как Вы его понимаете. А также что Вы понимаете под клиентской частью приложения.

:-)))
У меня нет своей интерпритации на этот счет.
Просто все соответствует общепринятому.
Как, например, слово "велосипед".

Так_забежал_просто
Я работал с двумя разными системами, где клиента обновлять не надо было практически никогда, а Вы мне сейчас докажете, что такого быть не может :)

Жалко что Ваше виденье ограничеваеться только "двумя разными системами" web системами.. которые сделаны, как подозреваю, типа на PHP...


P.S.
Ладно, это уже все off-topic.

2 Так_забежал_просто
Поищите в интернете что такое web server а что такое application server,
и все Вам станет понятно - что и для чего нужно.

А говорить что "велосипед" это тоже "мотоцикл", можно конечно, у них (в большенстве случаев) по два колеса... :-)
Но думаю Вы нестанете утверждать и доказывать что "велосипед" = "мотоцикл"?
И рекомендовать делать из "велосипеда" "мотоцикл"?
Хотя всякое бывает :-))