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

← →
Сатир (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 тоже поддерживает ?

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

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

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

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

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

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

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

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

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

Сатир

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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