Использование пакетов в Оракле

← →
Сатир (2006-10-25 12:34) [0]

Вопрос к тем, у кого большой опыт разработки приложений на основе СУБД Оracle.
На данный момент в во всех программах (в одной известной компании)
все select-запросы жёстко зашиты в компонентах доступа к БД. В результате при изменении схемы или названия таблицы приходится искать эти запросы и править их в коде программ. После чего, естественно остаются такие запросы, которые остались несправленными в силу определённых причин.
Мною было предложено вывести все запросы из программного кода и организовать для них свой пакет, а каждый запрос оформить в виде хранимой процедуры с входными параметрами, которая будет возвращать открытый курсор. Но такое предложение не устроило руководителя проекта, потому что запросов очень много и для каждого нужно будет написать свою хранимую процедуру. Он предложил собрать все запросы в одной таблице и написать одну хранимую процедуру, в которую передавать ID запроса из таблицы, в которой он хранится. Но тут встала проблемма с переменным количеством входных параметров.
Как из Delphi вызвать хранимую процедую и передать ей переменное кол-во параметров с переменным названием самих параметров и их типов.
Вопрос №1: будет ли каждый раз разбираться хранящийся запрос в таблице, который мы будем передаваться на вход этой универсальной процедуры?
Вопрос №2: как реализовать из Delphi передачу переменного числа названий параметров , их типов и значений?
Вопрос №3: какие недостатки такого подхода и какое может быть альтернативное решение?(желательно перечислить возможные достоинства и недостатки той или иной схемы решения)

← →
Reindeer Moss Eater © (2006-10-25 12:38) [1]

В общем дурь все это.
Если схема переименована и она не текущая, то проблема решается синонимами.
Да и вообще.
Не надо придумывать проблему на пустом месте.

← →
Курдль © (2006-10-25 12:39) [2]

Предлагаю руководителя проекта убить об стену :(
Если он так "наруководил", что
> select-запросы жёстко зашиты в компонентах доступа к БД

← →
Игорь Шевченко © (2006-10-25 12:40) [3]

Курдль © (25.10.06 12:39) [2]

> Если он так "наруководил", что
> > select-запросы жёстко зашиты в компонентах доступа к БД

Э...а где их еще хранить ? :)

← →
Reindeer Moss Eater © (2006-10-25 12:41) [4]

Руководятела проекта надо убить. Но не за это.
А за то, что работоспособность проекта зависит от имени схемы.

← →
artemiy © (2006-10-25 12:45) [5]

Вообще то есть такое понятие как схема по умолчанию или синонимы. ИМХО либо делайте "алтер сессион" при логине либо используйте синонимы.
У нас лично так. При логине юзер по синониму вызывает функцию, которая возвращает ИМЯ_СХЕМЫ (зашитое в таблице параметров системы), клиент делает алтер сессион устанавливая данную схему по дефолту. Соотв во всесх запросах имя схемы не участвует.

← →
Reindeer Moss Eater © (2006-10-25 12:53) [6]

Кстати как именно пакет-то может помочь в этой беде?
Он же тоже принадлежит определенной схеме.

← →
Курдль © (2006-10-25 12:56) [7]

> Игорь Шевченко © (25.10.06 12:40) [3]
> Э...а где их еще хранить ? :)

Например, в ресурсах.
Или лишняя строка кода типа Query.SQL.Text := "select..." - это непозволительная трата человекочасов? :)

← →
Reindeer Moss Eater © (2006-10-25 13:00) [8]

Например, в ресурсах.

А DFM перестал быть ресурсом?

← →
Desdechado © (2006-10-25 13:00) [9]

Привязка к имени схемы - это как привязка к жесткому паролю или в IP сервера внутри EXE. Это всего лишь элемент настройки, который может быть вынесен вне программ.
Если используются несколько схем одновременно, то это тоже можно настроить вовне.
1. Хранение запросов в таблице - глупость, ибо они каждый раз будут компилироваться и разбираться. Да и поддержка этой таблицы - лишний геморрой.
2. Создание по процедуре на каждый запрос - тоже неэффективно, поскольку их будут сотни/тысячи. По одной с ними замучаешься разбиравться (темпаче, с правами), а запихивание в пакет их не спасет, т.к. тогда при малейшем изменении 1 запроса весь пакет перекомпилировать/пересобирать придется, а при командой разработке это смерть.

ALTER SESSION + внешняя настройка имени схемы + синонимы, если ничего не помогло

← →
Sergey13 © (2006-10-25 13:01) [10]

> [0] Сатир (25.10.06 12:34)
> В результате при изменении схемы
У вас разрабатываемая вами база разложена по разным схемам? Я по неопытности тоже наступал на эти грабли. Лучше от этого уйти, т.е. слить все в одну схему. Сопровождать станет намного проще и легче.

← →
Игорь Шевченко © (2006-10-25 13:05) [11]

Курдль © (25.10.06 12:56) [7]

> Или лишняя строка кода типа Query.SQL.Text := "select...
> " - это непозволительная трата человекочасов? :)

Ну да. Именно непозволительная. Очень меткое слово.

← →
Сатир (2006-10-25 13:07) [12]

> Предлагаю руководителя проекта убить об стену

это самое простое решение и самое неоригинальное.
к тому же, его сложно реализовать в программном коде:)

> Кстати как именно пакет-то может помочь в этой беде?
> Он же тоже принадлежит определенной схеме.

даже если и останется привязка к определённой схеме при вызове хранимых процедур, можно создать синоним.

а на счёт хранения запросов в локальных компонентах, а как на счёт переноса самого приложения на другую платформу или на другой язык программирования? опять все запросы набирать в каждом компоненте доступа к данным?
короче, туго тут у меня с идеологами, а на вопрос:"а что по этому поводу говорит теория?" - приходится постоянно слышать:"нету у нас времени книжки читать. работать нужно"
:-)

← →
Игорь Шевченко © (2006-10-25 13:09) [13]

> а на счёт хранения запросов в локальных компонентах, а как
> на счёт переноса самого приложения на другую платформу или
> на другой язык программирования? опять все запросы набирать
> в каждом компоненте доступа к данным?

А никак. Приложения такого рода не переносятся ни на платформы ни на языки программирования.

← →
Sergey13 © (2006-10-25 13:11) [14]

> а как на счёт переноса самого приложения на другую платформу
> или на другой язык программирования? опять все запросы набирать
> в каждом компоненте доступа к данным?

Ты много делал переновов на другие платформы и языки (а языки-то вообще нафига менять????)? Часто слышу про эту проблему. По моим наблюдениям обеспокоенность этой проблемой явно не адекватна самой проблеме.

← →
Курдль © (2006-10-25 13:12) [15]

> Reindeer Moss Eater © (25.10.06 13:00) [8]
> А DFM перестал быть ресурсом?

Я имел в виду ResourceString. А где Вы предпочитаете хранить данные, подверженные частым изменениям?

> Игорь Шевченко © (25.10.06 13:05) [11]
> Ну да. Именно непозволительная. Очень меткое слово.

Не думаю, что запись кода запроса в свойство компонента сильно ускорит разработку. Ведь наиболее сложные запросы (DML) требуются для модификации данных. А их уже так просто "в компоненте" не разместишь - только в обработчике типа OnApplyRecord.

← →
Sergey13 © (2006-10-25 13:15) [16]

> [15] Курдль © (25.10.06 13:12)

> Ведь наиболее сложные запросы (DML) требуются для модификации данных.
ИМХО, весьма спорное утверждение.

← →
Reindeer Moss Eater © (2006-10-25 13:17) [17]

Я имел в виду ResourceString. А где Вы предпочитаете хранить данные, подверженные частым изменениям?

И кто их меняет? Юзер? Программист?
Лично мне заменить текст запросов одинаково легко в обоих случаях.
В ресорстринг они, или в dfm ресурсе или в dfm файле.

даже если и останется привязка к определённой схеме при вызове хранимых процедур, можно создать синоним.

А что мешает создать синоним без пакетов?

← →
Игорь Шевченко © (2006-10-25 13:17) [18]

Курдль © (25.10.06 13:12) [15]

> Я имел в виду ResourceString. А где Вы предпочитаете хранить
> данные, подверженные частым изменениям?

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

> Не думаю, что запись кода запроса в свойство компонента
> сильно ускорит разработку. Ведь наиболее сложные запросы
> (DML) требуются для модификации данных. А их уже так просто
> "в компоненте" не разместишь - только в обработчике типа
> OnApplyRecord.

Собственно, давно придуманы компоненты a-la TUpdateSQL и их многочисленные аналоги. Там, собственно, запросы для модификации данных и живут себе.

← →
Курдль © (2006-10-25 13:19) [19]

> Sergey13 © (25.10.06 13:15) [16]
> ИМХО, весьма спорное утверждение.

Спорное, но не весьма! :)
Приведу пример, когда требуется замысловатое каскадное обновление нескольких таблиц БД в результате изменений, происшедших в наборе данных. Причем с учетом качества этих изменений (многие, конечно же, отправят меня в ветку "О пользе ХП":)

← →
Курдль © (2006-10-25 13:21) [20]

> Игорь Шевченко © (25.10.06 13:17) [18]
> А с какого перепугу тескты запросов считаются данными, подверженными
> частым изменениям ? Их что, можно безболезненно менять,
> не меняя логику программы ? Вот новость.

Приведу пример, который многие называют досужими фантазиями - переход на другую СУБД.

← →
Сатир (2006-10-25 13:22) [21]

> Ты много делал переновов на другие платформы и языки (а
> языки-то вообще нафига менять????)? Часто слышу про эту
> проблему. По моим наблюдениям обеспокоенность этой проблемой
> явно не адекватна самой проблеме.

а если нужно написать приложение как для настолных компов(разрабатываем на Delphi), так и для КПК, а так же приложение, написанное на Java и все они могут использовать один и тот же сложный запрос, в котором идёт привязка к имени схемы и имени таблицы, тогда при изменении имени схемы или названия колонки таблицы, придётся вносить изменения во все три приложения, которые используют этот запрос. не проще ли его вывести в хранимую процедуру и вызывать его из пакета?

← →
Игорь Шевченко © (2006-10-25 13:23) [22]

Курдль © (25.10.06 13:21) [20]

> Приведу пример, который многие называют досужими фантазиями
> - переход на другую СУБД.

И чем в этом случае может помочь хранение текстов запросов в ресурсах/коде ?
(Я уже не говорю о том, что это досужие фантазии).

← →
Sergey13 © (2006-10-25 13:25) [23]

> [19] Курдль © (25.10.06 13:19)
> Приведу пример, когда требуется замысловатое каскадное обновление
> нескольких таблиц БД в результате изменений

Вот-вот. Приведи пример запроса (можно не очень сложного) реализующего

> замысловатое каскадное обновление нескольких таблиц

8-)

← →
Игорь Шевченко © (2006-10-25 13:25) [24]

Сатир (25.10.06 13:22) [21]

> а если нужно написать приложение как для настолных компов(разрабатываем
> на Delphi), так и для КПК, а так же приложение, написанное
> на Java и все они могут использовать один и тот же сложный
> запрос, в котором идёт привязка к имени схемы и имени таблицы

А что, есть сервер Oracle для КПК ?
Есть предложение не оправдывать кривизну дизайна нереальными условиями.

← →
Курдль © (2006-10-25 13:25) [25]

> Игорь Шевченко © (25.10.06 13:23) [22]
> И чем в этом случае может помочь хранение текстов запросов
> в ресурсах/коде ?

Возможностью изменения ресурсов без перекомпиляции.

← →
Reindeer Moss Eater © (2006-10-25 13:26) [26]

не проще ли его вывести в хранимую процедуру и вызывать его из пакета?

А что мне помешает три раза в день менять имя ЭТОЙ хранимой процедуры и ее принадлежность к схеме?

← →
Reindeer Moss Eater © (2006-10-25 13:26) [27]

Возможностью изменения ресурсов без перекомпиляции.

паблишед свойства по определению уже и так в ресурсах живут.

← →
Игорь Шевченко © (2006-10-25 13:27) [28]

Курдль © (25.10.06 13:25) [25]

> Возможностью изменения ресурсов без перекомпиляции.

А зачем их менять ? Другая СУБД, я надеюсь, SQL тоже поддерживает ?

Если тебя не затруднит, приведи пожалйуста пример приложения, которое можно перенести на другую СУБД одним лишь изменением в ресурсах текстов запросов.

← →
Reindeer Moss Eater © (2006-10-25 13:30) [29]

Возможностью изменения ресурсов без перекомпиляции.

Мда.
Возможность просто сказочная.
30 тысяч компиляций во время разработки и отладки.
И тут появляется волшебная возможность избежать 30001 компиляции.
Это сколько же времени и денег можно сэкономить.
Просто жуть.

← →
Сатир (2006-10-25 13:30) [30]

> А что, есть сервер Oracle для КПК ?

есть клиентское приложение для КПК, использующее доступ к данным из Оракла

← →
Игорь Шевченко © (2006-10-25 13:32) [31]

Сатир (25.10.06 13:30) [30]

> есть клиентское приложение для КПК, использующее доступ
> к данным из Оракла

Я не совсем понимаю, нельзя ли подробнее (с сохранением коммерческих секретов, разумеется) ? Каким боком на КПК запрос исполняется ?

← →
Reindeer Moss Eater © (2006-10-25 13:32) [32]

Сатир

Дак делай. в чем проблема-то?
Круто-же получится.
Или есть сомнения?

← →
ANB © (2006-10-25 13:52) [33]

> ибо они каждый раз будут компилироваться и разбираться

А кэш зачем тогда ?
Ведь при выполнении запроса из клиента и динамический SQL работают по одной схеме.
ИМХО :
1) Уточнять схему в запросе константой - хреново. Тут поможет либо макрос, либо установка текущей схемы. Желательно не лазить по разным схемам.
2) Если запросов не сильно много, то и правда - удобнее положить их в пакеты (в один как раз необязательно - можно разбить по темам). Преимуществом будет видение в этих запросах пакетных переменных и констант, обнаружение синтаксических ошибок еще при компиляции.
3) Если уж запросов действительно сильно дофига, то можно и таблицу с их текстами. В таком случае придется в этой же таблице описать и параметры.
Самы простой способ передавать в процедуру непределенное число параметров - завести их дефолтовыми с именами p_1, p_2 . . p_N (побольше). Потом уже в хранимке лезть в таблицы текстов запросов и формировать переменный с нужными именами, подставляя нужные значения. Довольно геморно получится, плюс будет легко сломать, напутав с параметрами или текстом запроса. Причем ошибка вылезет при выполнении. Кстати, пихать опять таки имя схемы в заготовки запросов - будет очень хреново.

← →
ANB © (2006-10-25 13:54) [34]

> придется в этой же таблице

точнее завести еще одну/несколько

← →
Reindeer Moss Eater © (2006-10-25 13:56) [35]

> придется в этой же таблице

точнее завести еще одну/несколько

Ага.
Лучше служебную схему.
А еще лучше служебный сервер.
А имя служебного сервера хранить на служебном сервере №2
Что бы уж точно все было четко.

А имя служебного сервера № 2 запретить менять под страхом смерти.

← →
Polevi © (2006-10-25 13:57) [36]

неопределенное число параметров переавать одним хмл параметром

← →
Sergey13 © (2006-10-25 13:58) [37]

> А имя служебного сервера № 2 запретить менять под страхом
> смерти.

За этим должен следить сервер № 3. 8-)

← →
Danilka © (2006-10-25 14:05) [38]

[3] Игорь Шевченко © (25.10.06 12:40)
> Э...а где их еще хранить ? :)

Во вьюхах :))
Мое мнение, что для большинства случаев запросы, в которых происходят соединения таблиц, а не просто однотабличные выборки, следует обрамлять вьюхами, а на клиенте уже селект из этих въюх.

← →
Reindeer Moss Eater © (2006-10-25 14:05) [39]

Во вьюхах :))
Мое мнение, что для большинства случаев запросы, в которых происходят соединения таблиц, а не просто однотабличные выборки, следует обрамлять вьюхами, а на клиенте уже селект из этих въюх.

А где хранить запросы к вьюхам?

← →
Danilka © (2006-10-25 14:08) [40]

> А где хранить запросы к вьюхам?

я иногда храню, таки, в ресурсах :))
правда, не Дельфи, а c#.
просто не люблю многострочные строковые константы, загромождают код, неудобно.
А вот-так удобно:
string selectInvoiceSQL = res.GetString("selectInvoiceSQL");
OleDbCommand cmd = new OleDbCommand(selectInvoiceSQL, con);

← →
Polevi © (2006-10-25 14:11) [41]

>Danilka © (25.10.06 14:08) [40]
я можно так OleDbCommand cmd = new OleDbCommand("EXEC SelectInvoiceSQL", con);
в том и прелесть, само название процедуры говорит о многом

← →
Игорь Шевченко © (2006-10-25 14:11) [42]

Danilka © (25.10.06 14:05) [38]

> Во вьюхах :))
> Мое мнение, что для большинства случаев запросы, в которых
> происходят соединения таблиц, а не просто однотабличные
> выборки, следует обрамлять вьюхами, а на клиенте уже селект
> из этих въюх.

Вьюхи - еще большее зло, чем хранимые процедуры.

← →
Polevi © (2006-10-25 14:12) [43]

смелое утверждение

← →
Polevi © (2006-10-25 14:12) [44]

особенно если учесть что иногда без никак

← →
Danilka © (2006-10-25 14:16) [45]

[39] Reindeer Moss Eater © (25.10.06 14:05)
держать сложные запросы во въюхах удобно еще и тем, что, когда на реальных данных запрос получается слишком тормозной, его оптимизация никак не затронет клиентов, все делаешь на сервере.
Вобщем, для исправления ошибок проектирования, можно так сказать. :))

[41] Polevi © (25.10.06 14:11)
Можно. Но страшно. У меня фобия на это и на "select *", вобщем на те случаи, когда явно не перечислены поля. :))

[42] Игорь Шевченко © (25.10.06 14:11)
> Вьюхи - еще большее зло, чем хранимые процедуры.

Даже и незнаю что сказать. Либо LMD, либо байку про овощ в свое время. %))

← →
Игорь Шевченко © (2006-10-25 14:17) [46]

Danilka © (25.10.06 14:16) [45]

Я смайлик буду ставить в нужном месте. Тут есть соседняя ветка про то, что ХП являются чем-то лишним вроде пятого колеса в телеге.

← →
Danilka © (2006-10-25 14:20) [47]

[46] Игорь Шевченко © (25.10.06 14:17)
Ага, вижу :))

← →
Сатир (2006-10-25 14:46) [48]

> неопределенное число параметров переавать одним хмл параметром

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

← →
Reindeer Moss Eater © (2006-10-25 15:07) [49]

К тому же, получается для каждого датасета, нужно добавлять свой генератор xml-я, что не очень удобно.

Такие мелочи и так сильно пугают?

но опять возникает проблемма с открытием курсора, нужно постоянное заранее известное количество связанных переменных.

А ты не используй параметры вообще. Ага.
Формируй текст курсора как строку. Ага.
И открывай реф курсор.
Немного возни, зато все будет "крута".

Можно будет переименовывать таблицы и схемы хоть по сто пять раз на день.
Мегасистема.

← →
Курдль © (2006-10-25 15:09) [50]

> Игорь Шевченко © (25.10.06 13:27) [28]
> А зачем их менять ? Другая СУБД, я надеюсь, SQL тоже поддерживает
> ?

Ага! У одной запрос
"... T1 left outer join (T2, T3) on T2.T3_ID = T3.T3_ID and T2.T1_ID = T1.T1_ID"
а у другой:
"... T1 left outer join (T2 inner join T3 on T2.T3_ID = T3.T3_ID) on T2.T1_ID = T1.T1_ID"

> Если тебя не затруднит, приведи пожалйуста пример приложения,
> которое можно перенести на другую СУБД одним лишь изменением
> в ресурсах текстов запросов.

Да, легко. И не только "которое можно", а "которые перенесены". Пиши мне на мыло.

← →
ANB © (2006-10-25 15:10) [51]

> курсоры можно открывать только с заранее известным и постоянным
> числом параметров.

кто сказал такую глупость ? Почитай про биндовые переменные и их использование в динамическом SQL.

← →
Reindeer Moss Eater © (2006-10-25 15:14) [52]

Ага! У одной запрос
"... T1 left outer join (T2, T3) on T2.T3_ID = T3.T3_ID and T2.T1_ID = T1.T1_ID"
а у другой:
"... T1 left outer join (T2 inner join T3 on T2.T3_ID = T3.T3_ID) on T2.T1_ID = T1.T1_ID"

Смену компонентов доступа тоже правкой ресурса производить?
А, понял там у нас АДО/БДЕ!
А параметры подключения с одного типа сервера на другой?
И все это только ради того, чт бы не открывать еще один раз проект в ИДЕ?
Или это на тот случай, когда покупатель софта купит другой сервер?
Типа сменил в ресурсах нужные буквы и тревожить программера не надо?

:)

← →
Игорь Шевченко © (2006-10-25 15:15) [53]

Курдль © (25.10.06 15:09) [50]

> Ага! У одной запрос
> "... T1 left outer join (T2, T3) on T2.T3_ID = T3.T3_ID
> and T2.T1_ID = T1.T1_ID"
> а у другой:
> "... T1 left outer join (T2 inner join T3 on T2.T3_ID =
> T3.T3_ID) on T2.T1_ID = T1.T1_ID"

Воедино их свести не получается ? Так, чтобы обе СУБД понимали ?

> Пиши мне на мыло.

Написал

← →
Desdechado © (2006-10-25 15:24) [54]

> Вьюхи - еще большее зло, чем хранимые процедуры
А я таки солидарен. На все запросы вьюх не напасешься. Зато оптимизатором они пережевываются ГОРАЗДО хуже, чем простые запросы, особенно, если нужно объединить несколько вьюх, каждая из которых соединяет несколько таблиц.
По крайней мере, для FB1.5 и ORA9.2 это правда. Тормоза обеспечены.

← →
Игорь Шевченко © (2006-10-25 15:26) [55]

> Зато оптимизатором они пережевываются ГОРАЗДО хуже, чем
> простые запросы, особенно, если нужно объединить несколько
> вьюх, каждая из которых соединяет несколько таблиц

А примеры планов в студию можно ?
С вьюхами и без вьюх...

← →
Курдль © (2006-10-25 15:44) [56]

> Reindeer Moss Eater © (25.10.06 15:14) [52]
> Смену компонентов доступа тоже правкой ресурса производить?
> А, понял там у нас АДО/БДЕ!

Смена компонентов - это больное место Delphi. Однако, если смириться с некоторой потерей качества при использовании "родных" компонентов оракла, вполне подходящий вариант использования набора "SQL Direct".
А если оракл не предполагался - эти компоненты отлично себя зарекомендовали.

В проектах .NET проблема со "сменой компонентов" не стоит.

← →
Игорь Шевченко © (2006-10-25 15:45) [57]

Курдль © (25.10.06 15:44) [56]

> В проектах .NET проблема со "сменой компонентов" не стоит.

Разве ? А Corelab свои поделки для .Net от нечего делать продает ? :)

← →
Курдль © (2006-10-25 15:48) [58]

> Игорь Шевченко © (25.10.06 15:45) [57]
> Разве ? А Corelab свои поделки для .Net от нечего делать продает ? :)

Наверное... Я их поделки не покупал, т.к. не нуждался.

← →
Reindeer Moss Eater © (2006-10-25 15:52) [59]

Ну так все таки.
Сменили текст запросов во всех TQuery.
И даже сменили параметры TDatabase.
И все это путем ковыряния ресурсов.

Дальше запускаем нашу чудо-мега-программу после такой операции.
Допустим что-то несрастается с первого раза.
Продолжаем мучать бедный экзешник или воспользуемся IDE и его отладчиком?

Смысл-то великий в чем всей этй ботвы?

> Reindeer Moss Eater © (25.10.06 15:52) [59]
> Смысл-то великий в чем всей этй ботвы?

Смысл ботвы в том, чтобы предостеречь аутора от "собрать все запросы в одной таблице и написать одну хранимую процедуру, в которую передавать ID запроса из таблицы, в которой он хранится."

У аутора имена схем, таблиц и столбцов меняются как перчатки.
Кто его убережет от смены имен процедур и имен схем в которых процедуры живут.

← →
Сатир (2006-10-26 11:50) [62]

> Смысл ботвы в том, чтобы предостеречь аутора от "собрать
> все запросы в одной таблице и написать одну хранимую процедуру,
> в которую передавать ID запроса из таблицы, в которой он
> хранится."

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

> Но руководитель решил вообще ничего не трогать и оставить
> всё как есть.

Он показал себя мудрым руководителем. 8-)

> Sergey13 © (26.10.06 11:53) [63]
> Он показал себя мудрым руководителем. 8

Либо почитал советы про убийство об стену :)

← →
Сатир (2006-10-26 12:22) [65]

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

← →
sergey888 (2006-10-26 12:36) [66]

← →
Сатир (2006-10-26 13:31) [67]

> Скупой платит трижды!

а лох - по жизни:)

← →
Сатир (2006-10-26 15:06) [68]

> Почитай про биндовые переменные и их использование в динамическом
> SQL.

ref cursor нельзя использовать с динамическим SQL.

Сатир (26.10.06 15:06) [68]
а как же open ..for ..? или только динамический execute immediate считаете?

> ref cursor нельзя использовать с динамическим SQL.

можно.

Сатир (26.10.06 15:06) [68]

> ref cursor нельзя использовать с динамическим SQL.

create or replace function dyna_query(query varchar2) return sys_refcursor
as
rc sys_refcursor;
begin
open rc for query;
return rc;
end;
/

select dyna_query("select distinct owner from all_objects") from dual;

← →
Сатир (2006-10-26 16:23) [72]

млиа... нельзя использовать реф курсор для запроса с заранее неизвестным количеством связанных переменных

← →
Сатир (2006-10-26 16:24) [73]

вот вам пример из живого кода
if
fmSmallDict.RunDialog("select to_char(t.ID_TYPE_STUFF) id, t.NAME_TYPE_STUFF name from wk.wkv_type_staff t where t.sign_activity = 1", id, "Вид материала") then
F1BookImportWares.TextRC[aRow, aCol] := id;

это по сабжу...

Сатир (26.10.06 16:23) [72]

> нельзя использовать реф курсор для запроса с заранее неизвестным
> количеством связанных переменных

А нафига такой сыр-бор ?

> if
> fmSmallDict.RunDialog("select to_char(t.ID_TYPE_STUFF)
> id, t.NAME_TYPE_STUFF name from wk.wkv_type_staff t where
> t.sign_activity = 1", id, "Вид материала") then
> F1BookImportWares.TextRC[aRow, aCol] := id;

И чего тебе не нравится ? Кто-то что-то выбирает из данных запроса, затем это что-то выбранное идет в спредшит.

← →
Сатир (2006-10-26 16:32) [75]

мне не нравится, что этот запрос каждый раз будет разбираться Ораклом.
и что этот запрос жёстко зашит в коде

Сатир (26.10.06 16:32) [75]

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

А что, у вас использование Shared pool законом запрещено ? Так оракл на законы плюет, посмотри статистику, оцени количество ресурсов, потраченных на первый И ВСЕ ПОСЛЕДУЮЩИЕ разборы.

> и что этот запрос жёстко зашит в коде

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

← →
Сатир (2006-10-26 16:38) [77]

> если wk - это имя схемы, то проще синоним создать

на моё предложение создать синомимы, руководство ответило, что синонимы создавать не велено. причину не назвали.

Сатир (26.10.06 16:38) [77]

Твое руководство - твои проблемы :)

> [77] Сатир (26.10.06 16:38)
> на моё предложение создать синомимы, руководство ответило,
> что синонимы создавать не велено. причину не назвали.
Может оно (руководство) не поняло этого слова? 8-)

← →
Сатир (2006-10-26 16:53) [80]

> Может оно (руководство) не поняло этого слова? 8-)

как вариант:)

может тогда просто мягко рассказать какая это кульная вещь, все пользуются, не дай готт отстать от прогресса?:)

← →
Сатир (2006-10-26 17:10) [82]

> может тогда просто мягко рассказать какая это кульная вещь,
> все пользуются, не дай готт отстать от прогресса?:)

чем я и занимаюсь в начале каждого рабочего дня:)
короче, нужно накупить умных книжек и по подчёркивать нужные абзацы карандашём, а потом с ними идти к руководству.
а так, на слово, никто верить не хочет)

Запросы удобно во вьюхах хранить
Вообще надо по возможности минимизировать клиенсткое программирование

← →
Sergey Masloff (2006-10-26 22:49) [84]

Сатир (26.10.06 17:10) [82]
>короче, нужно накупить умных книжек и по подчёркивать нужные абзацы >карандашём, а потом с ними идти к руководству.
>а так, на слово, никто верить не хочет)
Знаешь, насчет умных книжек их надо на опыте проверять. Потому что если ко мне с книжкой так придет я для начала предложу релевантный тест придумать и на нем показать преимущества. Если они есть. Поставлю задачу. Установлю срок. Если это была просто болтовня по мотивам слышал звон не знаю где он - человек будет иметь бледный вид.

Kerk © (26.10.06 19:03) [83]

> Вообще надо по возможности минимизировать клиенсткое программирование

Да. В клиентском приложении должна быть одна кнопка: "Хочу, чтобы"

Использование пакетов в Оракле Найти похожие ветки