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

Откуда: Страна непреодолимых противоречий
Сообщений: 8553
softwarer
grexhide
Если не через API или не через триггеры INSTEAD OF то как ?

А откуда Вы выкопали такую постановку вопроса? Я ничего подобного не говорил.

Позволил себе вольность чуть по другому трактовать понятие CRUD: Создание, выборка, изменение, удаление (Create, Retrieve, Update, Delete)

softwarer

grexhide
Все это, конечно, выглядит довольно категорично, но в своих приложениях я уже полностью отказался от "прямых" DML со стороны клиента (не считая, правда, LOB полей).

Нисколько не возражаю. Я говорю о другом: о том, что отказываться от прямых DML можно ради разумных хранимок. Отказываться ради заведомо тривиальных - глупость.

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

И напрасно не возражаете ;) При, к примеру, тривиальном UPDATE на Instead Of - происходит "дергание" запроса в обзоре, в целях получить :OLD.поля. А их можно было бы и с клиента послать (тоже - еще тот вопрос - что эффективннее и грамотнее... впрочем, INSTEAD OF - таки имеет больше плюсов, чем минусов).

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

Откуда: Москва
Сообщений: 18337
softwarer
Я говорю о другом: о том, что отказываться от прямых DML можно ради разумных хранимок. Отказываться ради заведомо тривиальных - глупость.

Именно. И этот момент я уже подчеркивал неоднократно - разговор об "отказе от прямых DML" - это экстремизм и бессмыслица.
Выносить из клиента надо именно бизнес-логику в виде хорошо структурированного API, реализующего те или иные бизнес-операции.
С учетом того, что далеко не все бизнес-операции логично представляются набором операций select, insert, update и delete брать за основу такого интерфейса формовские процедурные блоки - неразумно.
А если не брать за основу для реализации бизнес-операций, то ареал не экстремистского применения оказывается более чем узок.
Потому и пишу - овчинка выделки не стоит :)
20 июл 06, 12:23    [2904123]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8553
Gluk (Kazan)
grexhide
Да, потеря ПРЕСЛОВУТОЙ производительности это минус


Мда, тебе ВЕЗЛО с задачами :(


Т.е. ? Все достигается разумным компромисом.
20 июл 06, 12:25    [2904133]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63932
Блог
grexhide
Позволил себе вольность чуть по другому трактовать понятие CRUD: Создание, выборка, изменение, удаление (Create, Retrieve, Update, Delete)

Тем не менее, по-прежнему не понял, откуда Вы взяли такую постановку вопроса.

grexhide
Ну почему же ? При должной снаровке и хорошей поддержке со стороны клиента (на автогенерациях) - процедуры - имеют смысл.

Хм. Скажем так, с моей точки зрения автогенерация кода имеет смысл только при преодолении таким образом недостатков заведомо убогого инструмента. В том, что касается манипулирования данными, Oracle к убогим не относится, смысла в автогенерации я не вижу, одни минусы.

grexhide
И напрасно не возражаете ;)

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

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

grexhide
Ну почему же ? При должной снаровке и хорошей поддержке со стороны клиента (на автогенерациях) - процедуры - имеют смысл.

Хм. Скажем так, с моей точки зрения автогенерация кода имеет смысл только при преодолении таким образом недостатков заведомо убогого инструмента. В том, что касается манипулирования данными, Oracle к убогим не относится, смысла в автогенерации я не вижу, одни минусы.


т.е. ? Oracle - как раз и не сильно удобный инструмент в этом плане. Есть таблица на 50-т полей. Не руками же вбивать 50-т имен полей в обзор, 2x50-т имен полей в "перекрытый" insert, 2x50 в имен перекрытый update ?

Небольшой плагин в PL/SQL Developer. Указываем целевую таблицу, вуаля - получаем заготовку триггера+обзора (или процедурного API).

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

Откуда: Москва
Сообщений: 18337
grexhide
т.е. ? Oracle - как раз и не сильно удобный инструмент в этом плане.
Нецелевое использование инструментов никогда не было простой задачей :)
grexhide
Есть таблица на 50-т полей. Не руками же вбивать 50-т имен полей в обзор, 2x50-т имен полей в "перекрытый" insert, 2x50 в имен перекрытый update ?

select tab_alias.* :)
20 июл 06, 12:43    [2904243]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
grexhide
Member [заблокирован]

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

select tab_alias.* :)


кхм. возможно. на практике - это разворачивается Oracle в "FILE_NAME1", "FIELD_NAME2" и т.д. (были какие-то проблемы с импортом-экпортом и правкой потом обзоров в PL/SQL Developer - в чем была суть, не помню).

Кроме того, не удобно т.к. не наглядно. К примеру:

есть CLI_ID (ID клиента). За счет явного указания полей можно получить описательные поля "рядом":

DOC$.CLI_ID, -- ID клиента
CLI$.NUM CLI_NUM, -- Код
CLI$.NAME CLI_NAME, -- Наименование

мелочь, а приятно (аргументация за стандарт применения ;).
20 июл 06, 12:59    [2904394]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
grexhide
кхм. возможно. на практике - это разворачивается Oracle в "FILE_NAME1", "FIELD_NAME2" и т.д.
Exactly! То же самое Вы делаете плагином ;)
grexhide
Кроме того, не удобно т.к. не наглядно. К примеру:
есть CLI_ID (ID клиента). За счет явного указания полей можно получить описательные поля "рядом":
DOC$.CLI_ID, -- ID клиента
CLI$.NUM CLI_NUM, -- Код
CLI$.NAME CLI_NAME, -- Наименование
мелочь, а приятно (аргументация за стандарт применения ;).

Автоматизация "comment on ..." - дело хорошее, но применительно к обсуждению не аргумент ибо имеет общеDDLную ценность :)
20 июл 06, 13:04    [2904444]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63932
Блог
grexhide
Небольшой плагин в PL/SQL Developer. Указываем целевую таблицу, вуаля - получаем заготовку триггера+обзора (или процедурного API).

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

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

Откуда: Страна непреодолимых противоречий
Сообщений: 8553
softwarer
grexhide
Небольшой плагин в PL/SQL Developer. Указываем целевую таблицу, вуаля - получаем заготовку триггера+обзора (или процедурного API).

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


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

softwarer

От того, что в дополнение к табличке сгенерирована вьюха с тройкой триггеров

INSTEAD OF INSERT OR UPDATE OR DELETE - триггер один.

softwarer

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

Мелочь. За целостностью - безусловно нужно следить. Но это не сильно большая плата за возможность перекрытия базовых операторов и реализации на них бизнес-логики (или, что более актуально - материализации избыточных (денормализованных) полей. Гранты и прочее - не более чем. Какая суть разница - хоть на таблицу грант выдавай, хоть на обзор (1:1 - или/или) ?


softwarer

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

Глупо. Во первых - в таком случае мы опять имеем очень сильный базовый крен в сторону клиента. А во вторых, возвращаясь к нашим баранам (документ+проводки). На схеме INSTEAD OF триггеров мы получим в любом случае гарантированный результат - при любом DML на cущность (обзор) Документы мы в любом случае (в конечном счете) получим генерацию проводок и расчет отстатков, вне зависимости от того, с какой стороны и как это происходило (хоть со стороны клиента, хоть со стороны сервера, хоть - со стороны какой доп. пакетной обработки).

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

Если Вы мне покажете, как это можно сделать столь же эффективно и просто со стороны клиента, не прибегая к изыскам ORM (берем типовую модель Delphi и/или Oracle Forms), то я буду только благодарен.

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

К примеру, в приведенной схеме Документы-Проводки есть только два вызова:
а) INSERT INTO DOC (....) VALUES (....)
б) PCMN.DoRecalc - который пересчитывает уже централизованно все, что попросили для него триггеры (почему так ? потому что теже остатки считаются всего одним вызовом MERGE - централизованно по всем заинтересованным, читай заблокированным, аналитическим счетам).

Почему унифицироанный PCMN.DoRecalc ? - все потому же. Клиенту нужно знать ТОЛЬКО одну точку вызова (завершения транзакции) после ЛЮБЫХ операций с любой сущностью (обзором). Больше централизации - больше порядка и меньше головной боли. Впрочем, может быть это - для кого это и есть крамола (в погоне за той самой ПРОИЗВОДИТЕЛЬНОСТЬЮ сервера Oracle ;)
20 июл 06, 13:35    [2904696]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
OracleX
Member

Откуда:
Сообщений: 1998
Аргументы за отказ от традиционного SQL на клиенте в случае тривиальных CRUD-процедур:

1. Инъекция в вызов хранимки чувствует себя не так просторно, как в случае SQL.
2. Тривиальная хранимка по мере развития системы может становиться сложнее.
3. Программа на клиенте меньше подвержена изменениям (старая копия БД лучше дружит с exe-копиями).
4. Централизованный доступ штатными средствами ко всему, что касается БД.
5. Некоторые аргументы "против" (Order by, фильтры, переключение контекста, "выгнать всех из базы")
во многих конкретных случаях не приводят к ущербности приложения и качеству его обслуживания.

Аргументы против:

1. Пара курсоров.
2. Более сложная реализация типового приложения.
3. Более сложная реализация клиентской части не только для Oracle (при 2-уровн.арх.).
4. Order by, фильтры для больших резалт-сетов приводят к необходимости использования динамического SQL.
5. Для Insert, Update либо нужно ограничиться типовыми операторами, либо использовать динамический SQL.
6. Экземпляр одновременно обслуживает много схем-клонов.
7. Не типовые случаи.
20 июл 06, 13:36    [2904700]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
grexhide
Если Вы мне покажете, как это можно сделать столь же эффективно и просто со стороны клиента, не прибегая к изыскам ORM (берем типовую модель Delphi и/или Oracle Forms), то я буду только благодарен.

Одна аббревиатура. CDC.
20 июл 06, 13:47    [2904774]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
OracleX
1. Инъекция в вызов хранимки чувствует себя не так просторно, как в случае SQL.
Звучит как заклинание. На практике в чем выражается степень вольготности?
OracleX
2. Тривиальная хранимка по мере развития системы может становиться сложнее.
Это убийственный аргумент для неподготовленных умов. В реальной жизни этого либо никогда не происходит, либо надо опять уходить от CRUD к бизнес-API. Поэтому затраты на разработку и сопровождение CRUD "на будущее" не оправдаются.
OracleX

3. Программа на клиенте меньше подвержена изменениям (старая копия БД лучше дружит с exe-копиями).
???? Весь мой небогатый опыт протестует :)
OracleX
4. Централизованный доступ штатными средствами ко всему, что касается БД.
Обычный table-based block - это не "штатное" средство?
OracleX
5. Некоторые аргументы "против" (Order by, фильтры, переключение контекста, "выгнать всех из базы")
во многих конкретных случаях не приводят к ущербности приложения и качеству его обслуживания.
Забыли добавить - в узком классе конкретных приложений :)
OracleX
2. Более сложная реализация типового приложения.
3. Более сложная реализация клиентской части не только для Oracle (при 2-уровн.арх.).
4. Order by, фильтры для больших резалт-сетов приводят к необходимости использования динамического SQL.
5. Для Insert, Update либо нужно ограничиться типовыми операторами, либо использовать динамический SQL.

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

Откуда: Страна непреодолимых противоречий
Сообщений: 8553
andrey_anonymous
grexhide
Если Вы мне покажете, как это можно сделать столь же эффективно и просто со стороны клиента, не прибегая к изыскам ORM (берем типовую модель Delphi и/или Oracle Forms), то я буду только благодарен.

Одна аббревиатура. CDC.


CDS - Change Data Capture over LogMiner and others ?

Все это хорошо, но в теории (впрочем, как и большинство подобных средств).

Кроме того, лишнее "слабое звено".
20 июл 06, 13:56    [2904837]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
grexhide
Все это хорошо, но в теории (впрочем, как и большинство подобных средств).
Кроме того, лишнее "слабое звено".

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

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

Итого - создаем два нафиг не нужных объекта.


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

Мне сложно показать это на примере, но это выглядело именно так: выбрасывались сотни строк безумного делфийского кода (на тему сотен датасетов, ParamByName и прочей ереси).

При этом надежность и (и даже производительность) увеличивалась в несколько раз. Сответственно снижались затраты на тупое кодирование.

Впрочем, тут можно привести еще один довод в оправдание: реальность объективна, в любом случае - тем или иным образом придется реализовывать подобную бизнес логику на любом уровне. По более простого и эффективного уровня, чем обзоры+INSTEAD OF+расчетные процедуры в пакетах - я еще не видел.
20 июл 06, 14:04    [2904890]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8553
andrey_anonymous
grexhide
Все это хорошо, но в теории (впрочем, как и большинство подобных средств).
Кроме того, лишнее "слабое звено".

Аргументировать? :)


Аргумент очень прост:

- не везде работает (к примеру - отсутствует в 10g XE)
- требует дополнительного освоения разработчиками и администраторами
- не совсем то, что нужно для конечной задачи
- ээээ... гибкости - тоже, мягко говоря, не очень
20 июл 06, 14:07    [2904908]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8553
Да и "слабое звено" - это скорее из отряда - очень специфичные и узкоспециализированные функции Oracle - очень часто очень даже не мейнстримовые. При переходе между версиями - постоянные проблемы. Кроме того, очевидный "черный ящик" (т.е. неочевидные проблемы даже при эксплуатации).
20 июл 06, 14:09    [2904922]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
grexhide
- не везде работает (к примеру - отсутствует в 10g XE)
Независимость от БД? Ну-ну... Уверяю Вас, instead of не работают на oracle lite ;)
grexhide
- требует дополнительного освоения разработчиками и администраторами
Это, простите, совсем не аргумент. Освоения требуют любые изменения сущенствующего порядка вещей.
Вы же сами спрашивали "а как иначе", никто не навязывался.
grexhide

- не совсем то, что нужно для конечной задачи
Про конкретные задачи softwarer уже говорил - есть задачи, где instead of будет оптимальным решением. Однако Вы все пытаетесь обобщить этот частный опыт до общемировых масштабов, что не может не вызывать критики.
grexhide
- ээээ... гибкости - тоже, мягко говоря, не очень

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

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


Вот в том то и проблема. Я действительно обобщил эту практику до всех операций взаимодействия Пользователь<->Клиент (блок)<->Сервер.

Потому и затеял обсуждения, т.к. "гложут смутные сомненья".

Но вот аргументов против я не увидел вовсе. Те аргументы, которые приводились - оказались вовсе не аргументами. Да и "недостатки" приведенные OracleX к CRUD в случае INSTEAD OF - не имеют оснований (кроме вопроса о двух курсорах, но это - в любом случае неизбежно - их придется открывать на клиенте , в т.ч., вопрос только - как).

andrey_anonymous

Да что Вы говорите... Куда это неможно изогнуть? :)


лучше скажите, куда это можно вообще прилепить.
20 июл 06, 14:45    [2905156]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63932
Блог
grexhide
Соседа такого нужно мочить.

Эффективнее мочить технологию, из-за которой возникает потребность мочить соседа.

grexhide
Впрочем, практика "все девелоперы работают с одной базой" - увольте право,

Да какая разница? Он что check in не сделает?

grexhide
А "фигня" (автогенерация) эта нужна только на начальном этапе.

Точнее, на нем тоже не нужна.

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

grexhide
(А голова, кстати нужна, для того, чтобы думать)

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

grexhide
INSTEAD OF INSERT OR UPDATE OR DELETE - триггер один.

Что в лоб, что по лбу.

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

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

grexhide
Глупо. Во первых - в таком случае мы опять имеем очень сильный базовый крен в сторону клиента.

Полная чушь. Все абсолютно одинаково. На клиенте есть компонент (условно) SomeDataAdapter, с единственным значимым свойством UpdatingTable. И клиент знать не знает, генерит ли этот объект DML-и либо вызывает хранимки. Покажите, пожалуйста, хоть одну строку клиента, в которой разная реализация объекта вызовет "крен".

grexhide
А во вторых, возвращаясь к нашим баранам (документ+проводки). На схеме INSTEAD OF триггеров мы получим в любом случае гарантированный результат

Хм. Я не понимаю, с чем Вы спорите, явно с какими-то собственными представлениями. Судя по тому, что Вы говорите, Вы пытаетесь приписать мне позицию "не делать instead of триггеров". Исходя из этого, не вижу смысла комментировать остаток сказанного Вами.
20 июл 06, 14:50    [2905194]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63932
Блог
grexhide
И последний довод в сторону "нафигненужности". Как это не парадоксально звучит, но практически предложенный мной подход - упрощает клиента на порядки.

Мне сложно показать это на примере, но это выглядело именно так: выбрасывались сотни строк безумного делфийского кода (на тему сотен датасетов, ParamByName и прочей ереси).

Хм. Почему-то я уверен, что взяв типовую CRUD-программу, упрощу клиента на порядок, выкинув из него сотни строк безумного кода.

grexhide
При этом надежность и (и даже производительность) увеличивалась в несколько раз. Сответственно снижались затраты на тупое кодирование.

Скажем так, у меня есть подозрение, что ой как не зря Вам сложно показать это на примере.

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

grexhide
в любом случае - тем или иным образом придется реализовывать подобную бизнес логику на любом уровне.

Если Вы полагаете, что в любом случае тривиальных CRUD не будет - не понимаю, почему Вы с таким упорством отстаиваете их право на существование.
20 июл 06, 14:57    [2905240]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
OracleX
Member

Откуда:
Сообщений: 1998
Implementing CRUD Operations Using Stored Procedures

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

Однако, хотелось бы знать, в каких случаях оправдано использование тривиальных CRUD-процедур?
20 июл 06, 15:03    [2905279]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
grexhide
в погоне за той самой ПРОИЗВОДИТЕЛЬНОСТЬЮ сервера Oracle ;)


Ты уж поверь, иногда приходится считать микросекунды
Задача задаче рознь
20 июл 06, 15:08    [2905299]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли оформлять все Select"ы в виде хранимых процедур  [new]
grexhide
Member [заблокирован]

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


Похоже, вы просто невнимательно читаете.

Я говорил о подходе - клиент просто выполняет SELECT, INSERT, UPDATE, DELETE, как и раньше.

Но ! Все расчетные процедуры, бизнес логика и прочая - выносятся на серверный уровень за счет перекрытия.. SELECT (VIEW) , INSERT, UPDATE, DELETE (INSTEAD OF). Единственный минус - это необходимость поддерживать эти самые VIEW и Триггеры.

При этом подход - более прост и прозрачен, чем процедурный CRUD (REFCURSOR и процедурный DML API).

Не более того.

При этом функции клиента упрощаются на порядок (остается):

- организация запросов
- организация высокоуровневых DML (читай - механизм объектных событий, сообщений и т.д). До тех пор, конечно, пока это можно и нужно выполнять тремя базовыми объектными примитивами (Insert, Update, Delete).
- иначе - использование серверных процедурных вызовов напрямую (кстати, тоже за счет автогенерированного кода прокси модуля (TPCMN = class(TObject) 1:1 PCMN PACKAGE, к примеру).

Плюс - централизованный механизм транзакционной обработки (расчетов).

----

Кстати, насчет check-in - это тоже, еще вопрос. А контроль то где ? Или каждый разработкик - сам себе архитектор и нормоконтролер ? Нет уж, нет уж. Отвественный по модулю должен быть в любом случае, и желательно - в единственном числе.

---

А эмоции - лучше опустить (тем более, когда в них нет конструктива, а только общие фразы).
20 июл 06, 15:10    [2905306]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7   вперед  Ctrl      все
Все форумы / Oracle Ответить