Infernal V. RavenТакой вопрос уже проскакивал в этой ветке, но остался без должного внимания.
Сколь мне помнится, он получил именно то внимание, которого заслуживает.

Infernal V. RavenРазработчики информационных систем предпочитают не использовать ХП, в пользу альтернативных вариантов. В крупных систем это обусловленно многоплатформенностью. С другой стороны это связано с отличием работы ХП от обычного запроса(здесь в качестве примера сошлюсь на MS SQL). В связи с этим нужно альтернативное хранилище.
Хотелось бы понять, чем многоплатформенность мешает ХП так, как она не мешает "запросам из альтернативного хранилища". Имхо разные вещи свалены в одну кучу.

Infernal V. RavenПонятно что все упирается в потребности частого изменения версий и удобства модификации запросов.
Я бы сказал, главные критерии - это надежность (минимизация вероятности несинхронных изменений; изменений, которые делают одно, ломая другое) и удобство разработчика (как следствие - эффективность его работы).

Infernal V. RavenИз плюсов хранилища я вижу: централизованное хранение запросов,
Сам по себе это не плюс. Плюсом могут быть следствия из этого.

Infernal V. Ravenвозможность произвольной параметризации(т.е. некоторые параметры клиент может заполнить автоматически).
Чушь, простите. "Некоторые параметры клиент может заполнять автоматически" и без всякого хранилища; Вы снова связываете несвязанные вещи.

Infernal V. RavenИз минусов - такая же беда как и у ХП: меняем версию ХП - изволь поменять всех клиентов.
Далеко не только.

Прежде всего, стоит разобраться с вопросом совместимости. Совместимость структуры БД, серверного кода (ХП/запросов) и клиентского кода (полей в интерфейсе итп) - проблема, нуждающаяся во внимании при любом подходе. Решается она либо просто - регламентным принудительным обновлением всего везде, либо более сложно - введением того или иного справочника совместимости версий с запретом работы клиентов "не тех" версий. От расположения серверного кода особо не зависит; возможны симметричные варианты (типа - старый клиент с новой структурой работает со старым запросом и не работает с новым; старый клиент с новой структурой работает с новым запросом и не работает со старым).

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

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

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

Собственно, все.

Infernal V. RavenК вашему сожалению, с моей стороны и со стороны мне ответивших он получил немного больше.
Вы уж хотя бы не противоречьте сами себе :)

Infernal V. RavenМногоплатформенность подразумевает разные запросы для разных СУБД,
Я спрашивал не об этом. Поясняю: чем "разные запросы для разных СУБД" составляют проблему для ХП и не составляют проблему для "хранилища запросов"? Вам несложно положить в таблицу разные запросы для разных СУБД, но сложно инсталлировать разные ХП для разных СУБД?

Infernal V. Ravenзапуск ХП на них различен.
Ой, как страшно :)

Infernal V. RavenДалее думайте сами, хотя я убежден, что вы видели такие системы.
Я в том числе такую делаю. Почему и не вижу смысла бояться проблемы, решаемой за тридцать секунд.

Infernal V. RavenВода.
Не буду заставлять ее пить.

Infernal V. Raven softwarer Infernal V. Ravenвозможность произвольной параметризации(т.е. некоторые параметры клиент может заполнить автоматически).
Чушь, простите. "Некоторые параметры клиент может заполнять автоматически" и без всякого хранилища; Вы снова связываете несвязанные вещи.Ха. Сразу чушь. Я использую макросы, которые позволяют вставить в запрос некий кусок текста. Параметром я его ну никак не передам, неужели вам это удалось?
Простите, в каком веке Вы живете? Уже лет десять, как Query.Macros[] - столь же стандартный член класса, как и Query.Params[].

Далее, мне весьма нравится Ваш подход, ради которого я процитировал пару предыдущих реплик. Фактически: Вы использовали слово "параметры", а когда я использовал его же, радостно отреагировали - "Чушь, я имел в виду вовсе не параметры". Вызывает восхищение логикой вне зависимости от мифической проблемы с макросами.

Наконец, давайте таки попробуем подойти к вопросу как думающие люди. Вы говорите, что реализовав на сервере некоторый код, получаете преимущество в решении задачи "параметризации". Приведите пожалуйста пример того, что сделано из того, что было бы трудно решить на клиенте.

P.S. Подчеркну - я такую задачу знаю, встречался. Правда, она слишком редка, чтобы пытаться обосновать ей "глобальное хранилище запросов".

Infernal V. RavenВерсионность в хранилище поддерживать легче чем в ХП. ..... так вот при такой схеме это работает, в отличии от ХП.
Я был слегка удивлен тем, что сначала Вы сказали нечто совершенно другое, и тем не менее, реальной разницы тут нет, "отличие от ХП" скорее теоретическое.

"Передача разного списка параметров" - вовсе не основной фактор, мешающий версионности. Быть может я Вас удивлю, но и overloading хранимых процедур, и необязательные параметры существуют так же давно, как и макросы на клиенте.

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

Infernal V. RavenПочему без метаинформации? У меня как раз такой.
Во-первых, не приравнивайте "клиент, учитывающий метаинформацию" и "драйвер метаинформации", это разные вещи.

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

Если у Вас именно такой - это неплохо коррелирует с подменой параметров и макросов несколько ранее. Впрочем, тогда разговор о "проблемах централизованной параметризации" становится еще более.. необоснованным.

Infernal V. RavenМинусы перечислите пожалуйста, только без пафоса.
1. Код в "хранилище" не валидируется сервером. Это строка, которая может быть ошибочной либо стать ошибочной в результате последующих DDL, и это проявится только в момент ее выполнения. Несложно нарисовать сценарий, при котором такая ошибка не будет замечена во время неполного тестирования и проявится только у клиента (а полное тестирование системы, как мы знаем, обычно черезчур дорого для того, чтобы проводить его после каждого мелкого исправления).

2. Аналогично, этот код не участвует в стандартной интерпретации зависимостей. Для того, чтобы определить, какие объекты программы могут быть затронуты изменением, придется делать малонадежные запросы с like

3. Работа с "хранилищем" в дизайн-тайме максимально неудобна по сравнению с использованием ХП или кода на клиенте.

4. Адекватные по возможностям инструменты для такого режима не существуют. Их надо писать самостоятельно, затрачивая довольно много сил и все равно значительно уступая стандартным средствам. Отсутствует все - даже контроль версий потребует отдельных усилий, какой-нибудь "выгрузки построчно в txt".

Infernal V. RavenДля меня есть очевидный плюс - использование макросов в выражениях, т.е. подставление любых фильтров и ограничений в запрос. Альтернативой может быть только генерация запроса на лету на клиенте, что как вы сами понимаете, не является удобным.
Это даже не чушь, а не знаю как назвать. Весь мир много лет "подставляет любые фильтры и ограничения в запрос" и не испытывает от того никаких проблем. Может быть я не понимаю очередной уникальной особенности, которую Вы забыли упомянуть, но пока это звучит примерно так же, как звучало бы, например, "при работе с хранилищем запросов можно использовать исключения, а в других режимах - нельзя".

Infernal V. RavenКритерии надежности и удобства вряд ли стоит обсуждать,исходя из того, что надежность хранения зависит от СУБД, которая ХП хранит точно в таком же виде.
Судя по этому ответу, Вы либо не прочитали то, на что вроде бы отвечаете, либо сочли нужным "не прочитать".

Infernal V. RavenУдобство же зависит от разработчиков редактора запросов.
Не только. Еще от интегрированности этого "редактора запросов" в общую технологию работы. Если хотите, безусловно, можете разрабатывать собственный редактор "не хуже общеупотребимых".

CodenamedИ в нем хранимых процедур в принципе нет.

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

Как именно... скажу так, у меня довольно долго стояла задача писать код, который работал бы и в Delphi 2, и в Delphi 5 - то есть с большим разрывом между версиями и соответствующими изменениями библиотек. Я делал так: писал в Delphi 5, а для компиляции в D2 подключал дополнительную библиотеку с реализациями тех функций, которые в D5 были стандартными (чаще всего из D5 и брал их реализацию). Можно было бы поступить наоборот - писать в D2 и не пользоваться фичами D5. Но это был бы "медленный корабль".

Конкретно в этом случае - я бы "нормальный код" писал с хранимыми процедурами, а для "мобильного" использовал бы компонент, выглядящий для остального приложения как хранимка, а реально - исполняющий "код хранимки" с клиента. Где бы он хранил этот код - в таблице на сервере, или в ресурсах программы, или еще как - вопрос второй.

Infernal V. RavenОтнюдь. Где противоречие?
В том, что Вы сначала сказали "вопрос был обсужден недостаточно", а когда я ответил "имхо именно настолько, насколько заслуживает", Вы начали возражать, но не с общим смыслом "нет, он заслуживает большего", а с общим смыслом "его обсуждали достаточно много".

Infernal V. RavenБанально можно сделать несколько полей запросов, для различных СУБД.
Кодд пришел бы в восторг от этой мысли, но ответом на заданный вопрос это не является. Если не затруднит, попробуйте небанально.

Infernal V. Raven2) Макросы автоматом в код ХП ну никак не подставляются,
И не нужно. Такой реальной потребности нет, исключительно пожелания тех, кто тащит весь код в одно место или пытается натворить "суперпуперуниверсальную процедуру, которая будет вставлять любые данные в любую таблицу".

Infernal V. Ravenзначит ХП использовать нельзя,
Госсподи, что ж Вас так шарахает-то? Кому нельзя и почему?

Infernal V. RavenДалее следует вывод хранить их в клиенте, который на ходу не поправишь, либо в неком хранилище. Потом задумываешься, если часть запросов в хранилище, а часть в ХП, то собственно нафига ХП?
Замечательный пример того, что я называю "эскалация кривизны".

Давайте для начала я обрисую то, что полагаю прямым подходом. Итак:

- операция, например, "создать договор" реализуется ХП. И никакие макросы внутрь нее не нужны
- запрос, например, "список договоров с причиндалами" реализуется view. И никакие макросы внутрь него не нужны
- в клиенте содержится запрос вида, допустим, select from view where &filter и макрос спокойно подставляется

Теперь давайте смотреть. Сначала Вы придумываете некое "хранилище". Потом затыкаете одну из его дыр, делая собственный механизм макросов, и называете это преимуществом, недоступным без хранилища. Потом окончательно добиваете стандартные механизмы. Следующим шагом погрузитесь в их имитирование - например, поскольку Вы убили понятие подпрограммы, а следовательно и возможность вызвать одну подпрограмму из нескольких мест, Вам придется сделать понятие "макрос-подпрограммы", которая будет храниться в том же хранилище и подставляться в место "вызова" [отметим, я такое видел] Опять сочтете это крупной победой, хотя по сути это шаг вперед после двух назад. Ну и так далее до бесконечности.

Infernal V. Raven softwarer....Приведите пожалуйста пример того, что сделано из того, что было бы трудно решить на клиенте.Я уже говорил, есть динамически построенный фильтр, его надо подставь в разные запросы. В случае запроса это легко сделать.
И чем же это "трудно решить на клиенте"?

Infernal V. Raven softwarerP.S. Подчеркну - я такую задачу знаю, встречался. Правда, она слишком редка, чтобы пытаться обосновать ей "глобальное хранилище запросов".Я просил без пафоса.
Боюсь, я не в состоянии оценить, что Вы считаете пафосом и насколько. Если хотите, давайте предположим, что он врожденный и неотъемлимый.

Infernal V. Raven softwarerЯ был слегка удивлен тем, что сначала Вы сказали нечто совершенно другое, и тем не менее, реальной разницы тут нет, "отличие от ХП" скорее теоретическое.Совершенно нет. Как вы собираетесь хранить несколько ХП с одинаковым именем. Запросы же это позволяют.
Во-первых, у запросов нет имени (если мы не говорим о view и его аналогах), поэтому "позволяют" звучит несколько странно. Во-вторых...


Infernal V. Raven softwarer"Передача разного списка параметров" - вовсе не основной фактор, мешающий версионности. Быть может я Вас удивлю, но и overloading хранимых процедур, и необязательные параметры существуют так же давно, как и макросы на клиенте.ну и?
Ну и то, что благодаря им "версионность ХП" достигается так же легко, как "версионность запросов".

Infernal V. RavenС запросами легче работать, не надо вызывать например ALTER PROCEDURE,
Ну если "в UPDATE .. WHERE REQUEST_NAME = 'AAA' меньше букв, чем в 'ALTER PROCEDURE AAA'" то да, это может быть решающий аргумент. Как-то никогда не приходило в голову сравнивать подходы по такому критерию.

Infernal V. Ravenмассовые замены тоже делать легче.
Нда. Чувствую, если Вам захочется переименовать таблицу A в таблицу B, Вы обновите запросы методом


Infernal V. RavenВот хоть убей не понимаю чем ХП выигрывают у запросов? Приведите аргументы.
Уже были в прошлом письме, Вы их не понимаете. Такое впечатление, что Вы работаете.. ну может с MySQL, не знаю, право.

Infernal V. RavenСосредоточьтесь на главном - сабже.
Он того не стоит :)

Infernal V. RavenВообще принято запросы тестировать перед применением. Если Вы этого не делаете, я буду искренне удивлен. Достаточно просто запустить запрос в тестовом режиме и посмотреть ошибки. ХП пишутся точно также.
Тут был аргумент номер один, и Вы, судя по ответу, проигнорировали большую его часть. Признаться, Ваши ответы слегка напоминают мне тех поведение компиляторов, которые, натолкнувшись на непонятную конструкцию, пропускают все до точки с запятой и продолжают работать. С той разницей, что они высвечивают найденные проблемы, а Вы просто игнорируете.

Поясняю еще раз: любой DDL может сделать некорректным ранее корректный и проверенный запрос. С хранилищем Вы будете обязаны делать полное тестирование после каждого чиха. Полное, а не "запустить запрос в тестовом режиме".

Infernal V. RavenДа зависимостей нет. Я по этому поводу нисколько ни сожалею,
Без комментариев.

Infernal V. Raven softwarer3. Работа с "хранилищем" в дизайн-тайме максимально неудобна по сравнению с использованием ХП или кода на клиенте.Хм. Чушь. Мне понадобилось 15 минут чтобы интегрировать редактор запросов, который находится в системе, в Delphi, отдельным пунктиком в меню. Вдобавок такой дизайнер э-э-э... несколько удобней стандартных средств. Я уже говорил, что у нас MS SQL, следовательно QueryAnalizier. И так штук как AutoComplete мне там не хватало. Так что теперь даже не приходится переключаться в QA, чтобы посмотреть запрос.
Ну, Query Analizer безусловно дерьмо, но я в жизни не поверю, что под MSSQL нет нормальных инструментов.

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

Infernal V. RavenАй-ай, ну как же так. Ну какие инструменты? Перечислите что они должны уметь, т.е. их задачи, функции.
Ну, один Вы уже назвали. А дальше - сколько есть задач в работе с кодом, столько и инструментов. Прикажете зачитать Вам полное меню PL/SQL Developer-а плюс всех прочих? Конечно, если например не смотрите планы запросов - соответствующая кнопка вам ни к чему.

Infernal V. RavenДа и знаете, на самом деле мне легче было написать апдейтер запросов, чем апдейтер ХП. Все с поддержкой версионности и т.д. Просто по времени сравниваю.
Если предположить, что это утверждение правда, Вы снова вляпались в противоречие. Одним из тезисов этого утверждения является "Вы написали апдейтер ХП с поддержкой версионности". Не знаю, зачем такой зверь нужен, но его существование противоречит Вашему более раннему утверждению насчет проблем поддержки версионности в случае ХП.

Infernal V. RavenВы не поняли мысль. ХП хранятся в виде кода, в системных таблицах. Надежность хранения зависит от СУБД, значит условия хранения запросов и ХП равны. Вы имели ввиду какую-либо другую надежность?
Попробуйте таки читать то, но что отвечаете. А то Вы сначала ляпаете "вода", а потом переспрашиваете.

Infernal V. RavenВо-вторых, запросы запросами, значит, никто стандартные средства не отменяет. Т.е. хочешь пиши в стандартном редакторе, хочешь - в родном.
Угу, все верно. Вот только нормальные редакторы почему-то умеют работать с ХП и не умеют - с "хранилищами". Соответственно, та операция, которая с ХП делается за пару секунд (найти - поменять - откомпилировать и сохранить) в случае с хранилищем превращается в целую эпопею. А так конечно да - хочешь, пользуйся.

Infernal V. RavenВообщем недостаток хранилища есть - отсутствие связей, не споришь никак. Хотя теоретически можно редактор написать таким образом, чтобы он делал такую проверку, хотя это трудоемко и ИМХО бессмысленно.
Отсутствие не связей, а вообще всего кроме сугубого минимума. И постепенное мучительное добавление чуть более широкого минимума. Скажем, я бы посмотрел, как Вы собираетесь реализовывать таким образом аналог пакетов.

Почему я говорю "мучительное" - потому что видел такую систему, доведенную до... апофеоза. Довольно простой "запрос" после всех манипуляций и подстановок разворачивается в почти семь тысяч строк кода, которые на лету компилируются и выполняются - вместо всего лишь N вызовов подпрограмм.

SPQRЗапрос всего лишь показывает степень перегруженности ф-ции to_char в пакете Standard, owner SYS :)
Забейте. Валерий продемонстрировал квалификацию и поймал меня за руку