Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7   вперед  Ctrl      все
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18399
grexhide
andrey_anonymous
grexhide
Как ни крути - а все равно нужно перепроверять все заинтересованные формы.

Откройте для себя библиотеки объектов ;)

;)) и перепишите несколько десятков человеко лет.
Простите, но это звучит смешно. "Скажите, как мне изменить свое приложение - только так, чтобы нигде ничего не трогать". С этим - к Хоттабычу.
Мы обсуждаем возможные подходы к разработке и сопровождению, а не перспективы переработки конкретного приложения - это отдельная тема и, как ни странно, тоже имеет свои подходы к решению.
grexhide

Впрочем, зачем так далеко ходить ? Посмотрите в строну, к примеру, EL- в JSP, Databinding в ADF, Data... чего то там в .NET, не говоря уже о "традиционных" блоках в Oracle Forms и датасетах в Delphi.
Все эти "библиотеки объектов" - чудным образом перестают показывать свою эффективность практически в любой среде (которая имеет элементы дизайнера интерфейсов).

Как раз про библиотеки объектов Forms я и говорил. Не только не перестают, но даже широко применяются.
Все дело в стандартах разработки и тщательной проработке этих самых библиотек.
20 июл 06, 17:00    [2906169]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 64025
Блог
chp
Что-то типа, очень навскидку:

Хм. Если Вы обратите внимание, в названном мной фильтре было одно условие, которое резко противоречит Вашему "что-то типа", а именно соединение условий операцией "или" вместо примененной Вами "и".

Ну и собственно ok, типа. Что Вы будете делать, если пользователь теперь захочет не просто ".... либо товар с ценой больше $1000", а "... либо товар с ценой > $1000 и цветом "красный""? "... либо товар с ценой > $1000 и (цвет красный или размер > 42)"?
20 июл 06, 17:09    [2906253]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8553
softwarer
grexhide
Но и целостной картины тоже не было предложено, не так ли?

1. Это не имеет отношения к делу. Я прошу Вас ответить на конкретный вопрос: зачем Вы возражаете мне, если Вам нечего возразить, а то что придумываете, оказывается возражением вовсе не мне?
2. В том контексте, в котором я говорил, предлагать целостную картину не требовалось, и задачи такой я не ставил.


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

softwarer
grexhide
softwarer
grexhide
а находится целиком в отвественности разработчика

Хм. То есть, если в таблицу добавится поле, разработчик таки будет руками добавлять его в код? Не перегенерирует?

В случае VIEW+INSTEAD OF - нет. Пока требуется править вручную. Утомительно, но после правки вручную - нет реальной возможности выделить первоначально генерированые участки и уже осмысленное кодирование.

Хм. Похоже, этот абзац уже не нуждается в комментариях.

Итак, давайте сравним два подхода. В первом случае мы генерим 1000 "тупых" процедур, правим в ним 100 "умных" участков, дальше вносим все изменения руками. Во втором случае мы делаем компонент, который генерит "тупой" код на лету, если для данной конкретной таблицы/операции не задано "умного". Задаем ему 100 "умных" фрагментов (в виде хранимок или любом другом), дальше работаем абсолютно нормально, тупого кода разработчик вообще никогда не видит. Выводы?

Выводы все те же:

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

- второй случай на тему "умного" компонента с "хранимками", извините, откровенно повеселил. Т.е. Вы предлагаете все потоки пресловутого бизнес-процесса данных делать ТОЛЬКО через компонент, который реализован на клиенте ? И что тут нормального ? Очевидная утопия.

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

Говоря проще. Одна форма (один блок) 1:1 связь с сервером, и ничего больше.

Поток обработки (расчетов) к визуализации, отношения не имеет, смысл городить эти "тупые" и "не тупые" компоненты с генерацией кода на лету ?
20 июл 06, 17:18    [2906307]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
chp
Member

Откуда: Ярославль
Сообщений: 172
softwarer
Хм. Если Вы обратите внимание, в названном мной фильтре было одно условие, которое резко противоречит Вашему "что-то типа", а именно соединение условий операцией "или" вместо примененной Вами "и".
Лоханулся, признаю. Но считаю, что это просто придирка с вашей стороны (уже не первая позволю себе заметить). Моей целью было указать примерный способ решения и мои ответ его демонстрирует.

softwarer

Ну и собственно ok, типа. Что Вы будете делать, если пользователь теперь захочет не просто ".... либо товар с ценой больше $1000", а "... либо товар с ценой > $1000 и цветом "красный""? "... либо товар с ценой > $1000 и (цвет красный или размер > 42)"?

Во-первых поговорю с заказчиком и спрошу а действительно ли ему оно надо?
Если все-таки надо, то тогда буду применять динамический SQL. Это, пожалуй,одна из немногих областей его применения действительно полезная и практически незаменимая.
20 июл 06, 17:24    [2906353]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18399
grexhide
Я бы сказал проще. От клиента Delphi требуется только одно - визуализация данных, читай - интерфейс пользователя (к серверу). Все, что к этому не имеет отношения (а тем более вопросы "тупой" или "не тупой" автогенерации кода для операций, бизнес-процессов и т.д. и пр.), априори должно быть реализовано на другом уровне.

Вы слишком категоричны.
1) Клиенты БД бывают разные. Бывают интерактивные, а бывают и пакетные - интеграция, предобработка и т.д.
2) Даже для интерактивного клиентского РМ утверждение ИМХО слишком сильное. Логика визуализации далеко не всегда тривиальна, особенно если в системе более одного РМ, и в ряде случаев предъявляет свои требования к "наборам данных".
3) Как ни странно, бизнес-логика легче переносится на сервер приложений именно из клиентских модулей - в этом смысле излишняя централизация вредит "развитию" приложения. А это уже ведет к утрате маркетинговой привлекательности, поскольку "модные" нынче технологии не поддержаны ;)
20 июл 06, 17:28    [2906384]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 64025
Блог
grexhide
Странная посылка. Предглагаю ее опустить и сослаться на то, что мы говорим, не совсем следя за контекстом и не совсем понимая друг друга. Но Ваши выводы о "придумывании".... Честно говоря, мне не понятно, что Вы хотите этим сказать ! Вы вынесли ряд резких замечаний, часть не в тему и вообще не в
контекст, я лишь попытался переправить разговор в более контруктивное русло.

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

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

grexhide
- Вы, к сожалению утрируете ситуацию.

Похоже, Вы называете утрированием все, что не похоже на Вашу частную задачу.

grexhide
На 1000 "изначально тупых" процедур (вернее триггеров) у нас будет как минимум 1000 "умных" участков в них (иначе - зачем затевать все это ?)

Как минимум? То есть как максимум будет много больше, например 10'000? То есть, если я правильно понимаю, Вы склоняете к тому, что сгенерированный код составляет малую часть от приложения, то есть в итоге - к тому, что он особо не нужен?

grexhide
- второй случай на тему "умного" компонента с "хранимками", извините, откровенно повеселил. Т.е. Вы предлагаете все потоки пресловутого бизнес-процесса данных делать ТОЛЬКО через компонент, который реализован на клиенте ? И что тут нормального ? Очевидная утопия.

Если у Вас в глазах кривое зеркало, веселитесь. Так или иначе, уже есть польза от беседы.

grexhide
Говоря проще. Одна форма (один блок) 1:1 связь с сервером, и ничего больше.

То есть, если я правильно понимаю, уходим в грех под названием "затачивание сервера под клиента". Поясняю: требование изменить интерфейс приводит к тому, что мы лезем дорабатывать сервер так, чтобы соблюсти 1:1.
20 июл 06, 17:29    [2906394]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18399
chp
Во-первых поговорю с заказчиком и спрошу а действительно ли ему оно надо?
Если все-таки надо, то тогда буду применять динамический SQL. Это, пожалуй,одна из немногих областей его применения действительно полезная и практически незаменимая.

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

А все - от стремления к "наукообразию".
"В европах шурупы давно не закручивают, там теперь модно гвозди забивать молотками. А мы чем хуже? Будем забивать шурупы микроскопами..."
Грустно, господа.
20 июл 06, 17:35    [2906442]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
john smth
Member

Откуда:
Сообщений: 20
Извините, что вмешиваюсь... тут уже столь бурная дискуссия пошла... ;)
но вот меня заинтересовала такая тема:
softwarer

Ну и собственно ok, типа. Что Вы будете делать, если пользователь теперь захочет не просто ".... либо товар с ценой больше $1000", а "... либо товар с ценой > $1000 и цветом "красный""? "... либо товар с ценой > $1000 и (цвет красный или размер > 42)"?


а как это реализуется у Вас в клиенте?.. Пользователь имеет возможность писать скрипты или интерфейс каким-то образом поддерживает генерацию произвольных запросов?.. Если последнее, то ведь всё равно приходится накладывать некие ограничения на набор инструментальных средств пользователя и чем такая генерация запроса на клиенте принципиально отличается от динамического SQL на сервере?..
20 июл 06, 17:42    [2906502]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 64025
Блог
chp
Лоханулся, признаю. Но считаю, что это просто придирка с вашей стороны

А зря. По той простой причине, что пользователь в этом месте может выбрать как "И", так и "ИЛИ". Конструкция фильтра может быть сколь угодно сложной.

chp
Моей целью было указать примерный способ решения и мои ответ его демонстрирует.

Хм. Боюсь, этот способ решения не решает ту задачу, о которой я говорю. Это тот же самый QBE, который, конечно, можно бесконечно дорабатывать [тратя время и силы], добавлять все новые и новые заранее придуманные варианты и каждый раз напарываться на то, что существуют варианты, этим фильтром нереализуемые.

chp
Во-первых поговорю с заказчиком и спрошу а действительно ли ему оно надо?

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

chp
Если все-таки надо, то тогда буду применять динамический SQL. Это, пожалуй,одна из немногих областей его применения действительно полезная и практически незаменимая.

Хм. Итого, если просуммировать получается:

  • В большинстве случаев формируем переусложненный, неудобный и неэффективный SQL, пытаясь остаться в статических рамках.
  • В некоторых случаях таки удержаться в них не можем и идем делать динамический SQL.

    Имхо в данном случае "естественно динамичный" SQL с клиента оказывается явно предпочтительным решением.
  • 20 июл 06, 17:44    [2906522]     Ответить | Цитировать Сообщить модератору
     Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
    grexhide
    Member [заблокирован]

    Откуда: Страна непреодолимых противоречий
    Сообщений: 8553
    softwarer

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

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

    Дословно: "Все это общая философия. Практика говорит несколько о другом."
    Это было применительно к цитате, приведенной в Вашем посте. Жаль, что Вы это приняли на личный счет (до уровня "не совсем этичный").

    Впрочем, повторюсь: к сожалению, Вы не совсем внимательно читаете посты.

    softwarer

    grexhide
    - Вы, к сожалению утрируете ситуацию.

    Похоже, Вы называете утрированием все, что не похоже на Вашу частную задачу.


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

    А утрированием и неконструктивовм я назвал вашу дословную цитату (вот уж действительно, как Вы говорите, придуманную):

    автор
    "Итак, давайте сравним два подхода. В первом случае мы генерим 1000 "тупых" процедур, правим в ним 100 "умных" участков".

    Из отряда 100, 1000, впрочем и последовавших 10000.

    softwarer

    если я правильно понимаю, Вы склоняете к тому, что сгенерированный код составляет малую часть от приложения, то есть в итоге - к тому, что он особо не нужен?

    Да, составляет лишь часть приложения, в строках кода - 20-30% PL/SQL кода. Не нужен ? Т.е. ? В чем логика, если бы он не был нужен, его бы просто не было ! Просто код настолько тривиален, что его избыточно и крайне вредно писать вручную, не более того. Извините, вы же польуетесь автокомплитом в редакторе кода ? Это ли - не генерация ?

    softwarer

    grexhide
    - второй случай на тему "умного" компонента с "хранимками", извините, откровенно повеселил. Т.е. Вы предлагаете все потоки пресловутого бизнес-процесса данных делать ТОЛЬКО через компонент, который реализован на клиенте ? И что тут нормального ? Очевидная утопия.

    Если у Вас в глазах кривое зеркало, веселитесь. Так или иначе, уже есть польза от беседы.


    Какое отношение кривое зеркало имеет к вопросу и к необходимости (реально - отсутствующей) дополнительного кодирования компонент (помимо штатных) на стороне клиента ?

    softwarer

    grexhide
    Говоря проще. Одна форма (один блок) 1:1 связь с сервером, и ничего больше.

    То есть, если я правильно понимаю, уходим в грех под названием "затачивание сервера под клиента". Поясняю: требование изменить интерфейс приводит к тому, что мы лезем дорабатывать сервер так, чтобы соблюсти 1:1.


    В чем суть "крамолы затачивания" ? Если конкретно ? В аспекте озвученных мной постов ?
    20 июл 06, 17:49    [2906546]     Ответить | Цитировать Сообщить модератору
     Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
    andrey_anonymous
    Member

    Откуда: Москва
    Сообщений: 18399
    john smth
    а как это реализуется у Вас в клиенте?.. Пользователь имеет возможность писать скрипты или интерфейс каким-то образом поддерживает генерацию произвольных запросов?.. Если последнее, то ведь всё равно приходится накладывать некие ограничения на набор инструментальных средств пользователя и чем такая генерация запроса на клиенте принципиально отличается от динамического SQL на сервере?..

    Forms - штатно. QBE.
    Отличается следующим:
    1) Не надо делать руками генерацию sql-предожений, что на самом деле задача нетривиальная.
    2) Не надо изобретать сложных интерфейсов с хранимыми процедурами, сравнимых по сложности с генерацией самих динамических стейтментов.
    3) Не надо повторять работу, уже проделанную разработчиком инструментального средства.
    4) В случае формулирования пользователем условий, не позволяющих построить корректный запрос, инструмент содержит необходимую обработку ошибок, которую тоже не надо изобретать, достаточно кастомизировать.
    6) Для обеспечения QBE не требуется создавать и поддерживать дополнительных окон/полей/кнопок и логики.
    20 июл 06, 17:50    [2906553]     Ответить | Цитировать Сообщить модератору
     Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
    grexhide
    Member [заблокирован]

    Откуда: Страна непреодолимых противоречий
    Сообщений: 8553
    andrey_anonymous
    Простите, но это звучит смешно. "Скажите, как мне изменить свое приложение - только так, чтобы нигде ничего не трогать". С этим - к Хоттабычу.

    ну... ;) есть в этой истине доля истины. но даже в первом приближении - нам нужно аккуратно выстроить промежуточный слой между клиентом и таблицей сервера.. (к примеру - свести все документы в единую сущность, или объединить разные таблицы контрагентов: физических лиц и юридических). Вот тут и вступает в действие не Хотабыч, а именно механизм VIEW+INSTEAD OF.

    Зачем в сводить в единую сущность? Просто для того, чтобы привести в единообразие декларативную ссылочную целостность.

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

    andrey_anonymous

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

    И тем самым (в продолжение) мы получаем "прозрачную", но уже - и "чуть более интеллектуальную, чем тупые и прямые INSERT, UPDATE, DELETE" схему работы для любого уровня и типов клиентов ;) Без необходимости дополнительных телодвижений где либо, кроме как на уровне сервера Oracle (что и требовалось доказать).
    20 июл 06, 18:00    [2906615]     Ответить | Цитировать Сообщить модератору
     Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 64025
    Блог
    john smth
    а как это реализуется у Вас в клиенте?.. Пользователь имеет возможность писать скрипты или интерфейс каким-то образом поддерживает генерацию произвольных запросов?..

    Второе.

    john smth
    Если последнее, то ведь всё равно приходится накладывать некие ограничения на набор инструментальных средств пользователя и чем такая генерация запроса на клиенте принципиально отличается от динамического SQL на сервере?..

    Боюсь, не понял вопроса.

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

  • Заведомо бессмысленные операции (или то, что считаем таковыми). Например, условия вида ID_Записи <= Цена_Товара.

  • Возможности, не поддерживаемые инструментом генерации (например, аналитические функции).

    Что касается первых - об их отсутствии я не печалюсь :) Что касается вторых - есть куда развиваться. Тем не менее, по сравнению с QBE это практически полная свобода.

    Теперь про отличия от динамического SQL. По сути это и есть динамический SQL, передаваемый с клиента. От динамического SQL, сгенерированного на сервере, он отличается одним-единственным условием: на сервер крайне затруднительно передать информацию, которая позволила бы сконструировать SQL непосредственно на сервере. Почему затруднительно: потому что этой информации переменное количество, она сложно и малопредсказуемо структурируема и наконец, что наиболее противно, она завязана на интерфейс ввода. В результате, если захотим сочетать этот инструмент с процедурным подходом, придется либо передавать в процедуру сгенерированные на клиенте фрагменты SQL, либо громоздить сложный и дурной механизм, передавать информацию через XML или что-то подобное.

    Если говорить о передаче процедурам фрагментов SQL, основной возникающий в этом случае вопрос - а зачем тогда, собственно, нужны такие процедуры? Что остается из их преимуществ? Второй момент - фильтр вовсе не обязательно ограничивается клаузой where; иногда оправданно доработать from, а иногда - сделать select * from (основной запрос) where. То есть интерфейс передачи фрагментов становится сложным и запутанным. Ну а вопрос "нафига" никуда не девается.
  • 20 июл 06, 18:10    [2906668]     Ответить | Цитировать Сообщить модератору
     Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
    andrey_anonymous
    Member

    Откуда: Москва
    Сообщений: 18399
    grexhide
    нужно аккуратно выстроить промежуточный слой между клиентом и таблицей сервера.. (к примеру - свести все документы в единую сущность, или объединить разные таблицы контрагентов: физических лиц и юридических). Вот тут и вступает в действие не Хотабыч, а именно механизм VIEW+INSTEAD OF.
    Зачем в сводить в единую сущность? Просто для того, чтобы привести в единообразие декларативную ссылочную целостность.
    Простите, но тут я потерял нить. Зачем сводить в единую сущность телефонный номер VIP-клиента транспортной компании и "Камазы" из автопарка?
    grexhide
    При том, что нам уже - без разницы. Клиент видит только обзоры. Как они реализованы физически, и какие реальные механизмы их заполнения - это его уже абсолютно не волнует
    А зачем, простите, это надо? Только не теоретически - я очень низко оцениваю потенциальную пользу от таких "закладок".
    grexhide
    andrey_anonymous

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

    И тем самым (в продолжение) мы получаем "прозрачную", но уже - и "чуть более интеллектуальную, чем тупые и прямые INSERT, UPDATE, DELETE" схему работы для любого уровня и типов клиентов ;) Без необходимости дополнительных телодвижений где либо, кроме как на уровне сервера Oracle (что и требовалось доказать).

    1) Я далеко не уверен, что это требовалось не то что доказывать "нигде кроме как на уровне сервера Oracle", но даже пытаться это делать. Где плюсы по отношению к тем же штатным объектным библиотекам и библиотекам PL/SQL Forms?
    Минусы очевидны - Вы осложнили себе переход на трехзвенку и мало что получили от этих вложений в разработку в клиент-сервере.

    2) На самом деле с доказательством как-то не очень хорошо. Ну изменились атрибуты сущностей и/или связи между ними.
    - где гарантия, что имеющиеся представления и их логика корректны по отношению к новой схеме данных? Что они вообще могут быть адаптированы? Прежде чем ответить - задумайтесь, логика презентации клиента не поддерживает новых значимых атрибутов и не обеспечивает новых связей между РМ ...

    3) Пусть имеются таблицы A,B,C.
    Пусть логика презентации требует следующих "обзоров":
    V1 as A join B
    V2 as B join C
    V3 as B left join A left join C

    Пусть в первичный ключ таблицы C введен новый атрибут.
    Пусть создана таблица D, ссылающаяся на B

    - Как согласуются изменения логики триггеров соответствующих представлений?
    - Требуется ли доработка клиента для отражения этих изменений?
    20 июл 06, 18:19    [2906717]     Ответить | Цитировать Сообщить модератору
     Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
    andrey_anonymous
    Member

    Откуда: Москва
    Сообщений: 18399
    softwarer
    Тем не менее, по сравнению с QBE это практически полная свобода.

    А можно с этого места поподробнее?
    Есть подозрение, что Вы не все знаете про QBE :)
    20 июл 06, 18:22    [2906732]     Ответить | Цитировать Сообщить модератору
     Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
    grexhide
    Member [заблокирован]

    Откуда: Страна непреодолимых противоречий
    Сообщений: 8553
    andrey_anonymous
    Простите, но тут я потерял нить. Зачем сводить в единую сущность телефонный номер VIP-клиента транспортной компании и "Камазы" из автопарка?

    Опять же, утрируете. Я выше привел вполне разумные схемы сведения (из практики). Как правило, сведение/разведение диктуется или из изначально несколько неудачного проектирования схем или из практических нужд.

    Чаще - вопрос звучит даже проще - к примеру, в той же таблице контрагентов - масса информации, которая абсолютно не нужна в 95% случаев. Нам нужно выделить лишь наиболее часто используемые атрибуты (и снизить LIO, повысить фактор кластеризации и т.д. и т.п.). Этого можно достичь и обычными триггерами, но триггеры на обзоры - более предпочтительны, т.к. позволяют сделать дополнительное программное разделение (т.е. иметь возможность обходить само понятие триггеров там, где оно совсем не нужно, к примеру - при репликациях и пакетной обработке). Грубо говоря в данном подходе - триггеры на таблицы вообще исчезают как класс и очевидное зло.

    andrey_anonymous

    1) Я далеко не уверен, что это требовалось не то что доказывать "нигде кроме как на уровне сервера Oracle", но даже пытаться это делать. Где плюсы по отношению к тем же штатным объектным библиотекам и библиотекам PL/SQL Forms?

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

    Неужели не очевидно ?

    andrey_anonymous

    Минусы очевидны - Вы осложнили себе переход на трехзвенку и мало что получили от этих вложений в разработку в клиент-сервере.

    С точностью наоборот. Я получил сервер приложений, реализованный на Oracle RDBMS напрямую. Вложения получил очевидные - отсутствие необходимости в том самом сервере приложений. С учетом текущего состояния вопроса этих самых серверов приложений - выигрыш просто трудно измерить по многим параметрам. Считаете иначе ?

    andrey_anonymous

    2) На самом деле с доказательством как-то не очень хорошо.

    Доказательства на то и доказательства, что требуют, собственно говоря самого доказательства ;)

    andrey_anonymous

    Ну изменились атрибуты сущностей и/или связи между ними.

    - где гарантия, что имеющиеся представления и их логика корректны по отношению к новой схеме данных?

    А иначе что ? Где гарантия, что клиенсткие модули также корректны ?
    Тем более, не стоит забывать, что связь между сущностью/обзором и слоем клиента - это 1:M, при том, что M - этот - весьма условен.
    Подходом от обзоров/триггеров я получаю полную независимость и преемственность клиентов от текущего состояния дел в физической модели.
    Можно даже работать от китайского метода - т.е. полностью сохранять поведение "старых" схем (кстати, очень сильно помогает при поэтапном реинжиниринге и миграции).

    andrey_anonymous

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

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

    А заинтересованные формы правятся сразу по месту - иначе зачем нам вводить эти самые атрибуты ?

    Т.е. принцип преемственности в развии - сохранятся. Больной вопрос - кардинальное изменение/перестройка набора атрибутов в целом еще и по обзору. Впрочем, это в любом случае - больной вопрос.

    andrey_anonymous

    3) Пусть имеются таблицы A,B,C.
    Пусть логика презентации требует следующих "обзоров":
    V1 as A join B
    V2 as B join C
    V3 as B left join A left join C

    Пусть в первичный ключ таблицы C введен новый атрибут.
    Пусть создана таблица D, ссылающаяся на B

    - Как согласуются изменения логики триггеров соответствующих представлений?
    - Требуется ли доработка клиента для отражения этих изменений?


    - первичный ключ делать составным - это в любом случае - крайне плохая идея. Даже "ход" Oracle в OEBS с внесением ORG_ID в PK (признак подразделения) принес куда больше вреда, чем пользы, и был - совсем необдуманным шагом (и даже не IMHO).

    - согласуется логика триггеров по месту. Т.е. правятся триггеры по необходимости. Для клиента - нет никакой разницы. Он видит обзоры в том виде, в котором и раньше (как денормализованные универсальные отношения).
    20 июл 06, 18:50    [2906887]     Ответить | Цитировать Сообщить модератору
     Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 64025
    Блог
    grexhide
    Дословно: "Все это общая философия. Практика говорит несколько о другом."

    Да. И отметим, что "это" - переводится как "сказанное Вами, softwarer", а "практика" - как "моя, grexhide-а, практика".

    grexhide
    Это было применительно к цитате, приведенной в Вашем посте.

    Хм. Я не понимаю, чем "сказанное мной" отличается от "моего".

    grexhide
    Жаль, что Вы это приняли на личный счет

    Хм. А на чей же мне следовало принять?

    grexhide
    (до уровня "не совсем этичный").

    Хм.

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

    2. Поскольку Вы прокомментировали мое высказывание, я воспринимаю этот эпизод как неэтичный по отношению ко мне.

    grexhide
    Впрочем, повторюсь: к сожалению, Вы не совсем внимательно читаете посты.

    Допускаю, хотя пока что не увидел прямых доказательств. Однако, это очередное Ваше заявление, не относящееся к обсуждаемому предмету.

    softwarer

    grexhide
    - Вы, к сожалению утрируете ситуацию.

    [quot grexhide]Позволю уточнить - мы рассматриваем вопрос задачи - организации взаимодействия клиента и сервера в аспектах применения (и в каком виде) или не применения процедурных расширений (проблематики CRUD).

    При некоторых уточнениях готов согласиться.

    grexhide
    А утрированием и неконструктивовм я назвал вашу дословную цитату (вот уж действительно, как Вы говорите, придуманную):

    Вы, разумеется, вольны считать и называть как хотите. Насколько я понимаю, "утрирование и неконструктив" выражаются в том, что с Вашей точки зрения цифры или соотношения другие. Из чего следует два основных варианта:

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

    grexhide
    Из отряда 100, 1000, впрочем и последовавших 10000.

    То есть, если бы было 112, 988 и 11340 претензий бы не было? В чем суть?

    grexhide
    Да, составляет лишь часть приложения, в строках кода - 20-30% PL/SQL кода. Не нужен ? Т.е. ? В чем логика, если бы он не был нужен, его бы просто не было !

    Это если исходить из презумпции логичности имеющейся у вас реализации.

    Итак, судя по Вашим словам, у вас есть 20-30% тупого кода, который периодически приходится утомительно править руками. Каких-то заведомых плюсов от наличия такого кода пока названо не было. Итого - логичность сомнительна (не говорю неверна, но - не обоснована).

    grexhide
    Просто код настолько тривиален, что его избыточно и крайне вредно писать вручную, не более того. Извините, вы же польуетесь автокомплитом в редакторе кода ? Это ли - не генерация ?

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

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

    grexhide
    Какое отношение кривое зеркало имеет к вопросу и к необходимости (реально - отсутствующей) дополнительного кодирования компонент (помимо штатных) на стороне клиента ?

    Правильно ли я понимаю, что необходимость дополнительного кодирования плагина к PL/SQL Developer Вы полагаете реально существующей, а необходимость кодирования упомянутых компонент - реально отсутствующей?

    Если так, боюсь, это свидетельствует об изначально необъективном подходе.

    grexhide
    В чем суть "крамолы затачивания" ? Если конкретно ? В аспекте озвученных мной постов ?

    В постах этой темы, исключая тот фрагмент, на который я отвечал, Вы эту тему не упоминали.

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

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

    Отчасти моя реакция вызвана тем, что мне довелось слегка поковыряться в приложении, построенном именно по такому принципу. И мой вердикт по тому случаю - уж лучше бы они все делали на клиенте.
    20 июл 06, 18:50    [2906890]     Ответить | Цитировать Сообщить модератору
     Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
    grexhide
    Member [заблокирован]

    Откуда: Страна непреодолимых противоречий
    Сообщений: 8553
    andrey_anonymous
    softwarer
    Тем не менее, по сравнению с QBE это практически полная свобода.

    А можно с этого места поподробнее?
    Есть подозрение, что Вы не все знаете про QBE :)


    ;) не будите в software-е зверя. Для него это "больной" вопрос.

    На самом деле можно посмотреть в демо последних наработок от DevExpress Quantum Grid.

    Едея - максимально навороченного визуального построителя типовых запросов (кстати, довольно утопичная). В Oracle Forms такое делается только вручную через SQL
    20 июл 06, 18:53    [2906911]     Ответить | Цитировать Сообщить модератору
     Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
    grexhide
    Member [заблокирован]

    Откуда: Страна непреодолимых противоречий
    Сообщений: 8553
    softwarer

    grexhide
    Из отряда 100, 1000, впрочем и последовавших 10000.

    То есть, если бы было 112, 988 и 11340 претензий бы не было? В чем суть?

    В соотношении естественно. 1000 тупых/100 не тупых дает качественную оценку "интеллектуальности" в целом ? ;)) Странно, а вроде даже и не пятница.

    softwarer

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


    Пожалуй пора прорезюмировать:

    Мысли об общих сентециях, оторванные от объективных реалий (преимущств) и искаженные субъективными ощущениями (неудачных) практик в любом случае приводят лишь к неадекватному восприятию действительности. При этом правило - справедливо для обоих сторон.

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

    Говоря проще - да, каждый волен строить так, как ему это удобнее и эффективнее. До тех пор, пока не будет предложен объективно более удачный вариант или доказано обратное. Вопрос же субьективного личностного восприятия/неприятия последнего - это даже не предмет обсуждения.
    20 июл 06, 19:07    [2906983]     Ответить | Цитировать Сообщить модератору
     Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
    Добрый докотор Айболит
    Guest
    Чуваки, пошли бы в рыгаловку какую, взяли пива и трендели там с друг другом. А? Глядишь еще б кто подключился? ;)

    P.S.
    ПальцЫ еще не отсохли клацать по клаве?
    20 июл 06, 19:07    [2906989]     Ответить | Цитировать Сообщить модератору
     Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
    grexhide
    Member [заблокирован]

    Откуда: Страна непреодолимых противоречий
    Сообщений: 8553
    softwarer

    Да. И отметим, что "это" - переводится как "сказанное Вами, softwarer", а "практика" - как "моя, grexhide-а, практика".
    grexhide
    Жаль, что Вы это приняли на личный счет

    Хм. А на чей же мне следовало принять?


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

    "Это" vs "Сказанное вами" не есть синонимы. В равной степени как и неопределенная форма: "практика" - не подразумевает безуслновного трактования как "моя личная практика" (a vs the)
    20 июл 06, 19:19    [2907040]     Ответить | Цитировать Сообщить модератору
     Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
    andrey_anonymous
    Member

    Откуда: Москва
    Сообщений: 18399
    grexhide
    Чаще - вопрос звучит даже проще - к примеру, в той же таблице контрагентов - масса информации, которая абсолютно не нужна в 95% случаев.
    Нам нужно выделить лишь наиболее часто используемые атрибуты (и снизить LIO, повысить фактор кластеризации и т.д. и т.п.). Этого можно достичь и обычными триггерами, но триггеры на обзоры...
    Простите, я Вас не понимаю. Можно ли как-то проиллюстрировать взаимосвязь триггеров и снижения LIO?
    grexhide
    Грубо говоря в данном подходе - триггеры на таблицы вообще исчезают как класс и очевидное зло.
    Ну вот, опять ROT...
    1) Триггеры не исчезают, они изменяют местоположение
    2) Логику триггеров Вы вынуждены продублировать в методах перестроения соответствующих агрегатов, в противном случае пакетные операции на таблицах приведут к data inconsistency.
    grexhide
    andrey_anonymous

    1) Я далеко не уверен, что это требовалось не то что доказывать "нигде кроме как на уровне сервера Oracle", но даже пытаться это делать. Где плюсы по отношению к тем же штатным объектным библиотекам и библиотекам PL/SQL Forms?

    Плюсы - разгрузка клиента от функций, которые на нем (только на нем) быть не должны. Обеспечение назависимости клиента от физической модели данных, внесение "прозрачного" программного слоя доп. обработки (независимого от конкретного клиента, только - от данных).
    Функции должны реализовывать логику. По отношению к физическому размещению у функций никаких обязательств нет.
    Что касается "прозрачности" и прочих ОО-идей, то плюсы от такой реализации так и не показаны.
    grexhide
    Неужели не очевидно ?
    К сожалению, нет... Есть иные системы ценностей и критерии "красоты", а именно:
    - стоимость разработки
    - стоимость сопровождения
    - реализованный функционал
    Ни по одному их этих пунктов убедительных преимуществ выбранной Вами схемы показано не было.
    grexhide
    andrey_anonymous
    Минусы очевидны - Вы осложнили себе переход на трехзвенку и мало что получили от этих вложений в разработку в клиент-сервере.

    С точностью наоборот. Я получил сервер приложений, реализованный на Oracle RDBMS напрямую.

    No comments.
    Считаю иначе.
    grexhide
    andrey_anonymous

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

    А иначе что ? Где гарантия, что клиенсткие модули также корректны ?
    Вот об этом я и говорю. Изменения бизнес-логики, как правило, требуют соответствующих изменений в логике представления.
    В Вашей схеме доработке подлежат не только клиентские РМ, но и соответствующие views. Т.е. на практике имеем более сложную и дорогую в сопровождении систему.
    grexhide
    Тем более, не стоит забывать, что связь между сущностью/обзором и слоем клиента - это 1:M, при том, что M - этот - весьма условен.
    Ну вот, приехали. Совсем недавно кто-то писал про 1:1...
    И если в 1:1 я верю, то в 1:М при М>1 - нет.
    Коэффициент повторного использования специализированного кода (а Ваши представления судя по Вашим словам таковыми и являются) находится ниже плинтуса. И в самом деле - кому нужен один и тот же клиент в двух экземплярах? =)
    grexhide
    Подходом от обзоров/триггеров я получаю полную независимость и преемственность клиентов от текущего состояния дел в физической модели.

    1) Полной ну никак не получаете. Тут уже Вы утрируете.
    2) Преемственность обеспечивается и без интерфейсных view.
    3) Независимость от физической модели - это утопия. Все, что Вы имеете - возможность иногда не деплоить клиентский модуль... Но это крайне незначительный бонус при наличии мало-мальски проработанной технологии развертывания и сопровождения приложений.
    grexhide
    Можно даже работать от китайского метода - т.е. полностью сохранять поведение "старых" схем (кстати, очень сильно помогает при поэтапном реинжиниринге и миграции).
    И что, часто ваша система находится в состоянии реинжиниринга и миграции таких масштабов, чтобы польза от удвоения усилий на сопровождение (кодируется новый функционал + обеспечивается bakward compatibility) была заметна?
    grexhide
    andrey_anonymous

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

    Не аргумент. Впрочем, я скажу проще - централизованно контролировать поведение схемы (модели) данных - намного проще. Ввод новых атрибутов, к примеру в сущность Документы - вообще может не сказаться на незаинтересованных клиентских формах - для них они просто не существуют.
    На формах, может, и нет, а вот на приложении - ДА.
    Простой пример: в документ вводится новый обязательный атрибут. Например, ИНН.
    Есть новые формы, которые этот атрибут вводить позволяют, и старые, для которых атрибут "не существует".
    Вариантов ровно два:
    1) "старые" формы становятся неработоспособными, поскольку "ORA-01400: cannot insert NULL..."
    2) Данные, введенные посредством "старых" форм, неконсистентны.
    И что имеем? Пшик?
    grexhide
    А заинтересованные формы правятся сразу по месту - иначе зачем нам вводить эти самые атрибуты ?
    ОТОЖ! Именно так - правятся. Так зачем править еще и какие-то view?
    grexhide
    andrey_anonymous
    - Как согласуются изменения логики триггеров соответствующих представлений?
    - Требуется ли доработка клиента для отражения этих изменений?

    - первичный ключ делать составным - это в любом случае - крайне плохая идея.
    Вы пытаетесь уйти от ответа :)
    grexhide

    - согласуется логика триггеров по месту. Т.е. правятся триггеры по необходимости.
    Как вычисляется необходимость? По факту несходимости квартального отчета?
    20 июл 06, 19:27    [2907068]     Ответить | Цитировать Сообщить модератору
     Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
    SeaQL
    Member

    Откуда:
    Сообщений: 40
    Мои пять копеек:
    при миграции на 10g была обнаружена интересная бага: запросы отлаживаемые и запускаемые на сервере (читай пакетные задания) и запросы запускаемые с клиента (формзы, репорты и пр.) бывало имели РАЗНЫЕ планы выполнения(!) и как следствие разное время выполнения!
    Посему в данном контекте считаю, что хранение/выполнение запросов предпочтительнее на сервере, как дающее более стабильные результаты. А клиент пусть кушает ref cursor.
    Хотя конечно утверждение не есть догма, в каждом конкретном случае своё решение.
    20 июл 06, 19:30    [2907073]     Ответить | Цитировать Сообщить модератору
     Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
    andrey_anonymous
    Member

    Откуда: Москва
    Сообщений: 18399
    grexhide
    Едея - максимально навороченного визуального построителя типовых запросов (кстати, довольно утопичная). В Oracle Forms такое делается только вручную через SQL

    Пример можно?
    Абстрактные построители, понятно, неинтересны.
    Вот есть форма, поля А1, А2, А3.
    Какой тип практически ценных запросов позволяет строить эта штука, который нельзя сделать посредством forms QBE?
    20 июл 06, 19:30    [2907076]     Ответить | Цитировать Сообщить модератору
     Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
    andrey_anonymous
    Member

    Откуда: Москва
    Сообщений: 18399
    SeaQL
    Посему в данном контекте считаю, что хранение/выполнение запросов предпочтительнее на сервере, как дающее более стабильные результаты.


    Не делайте мне смешно.
    Вы просто поленились разобраться в причинах явления.
    Это были РАЗНЫЕ запросы либо выполнялись в разных сессиях с различным окружением.
    20 июл 06, 19:34    [2907089]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7   вперед  Ctrl      все
    Все форумы / Oracle Ответить