|
|
|
ProC pro & contra
|
|||
|---|---|---|---|
|
#18+
Привет! Поделитесь опытом, пишущие на (и, возможно любящие) ProC. Чем он лучше/хуже своих альтернатив: пакаджей, ADO, OO4O ... Главное, чем лучше? Кирилл ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2003, 16:46 |
|
||
|
ProC pro & contra
|
|||
|---|---|---|---|
|
#18+
за: -технология на 10-летия -по кайфу знатокам Си -быстро работает Против -гетерогенная технология (Си плус СКуЛ) -затрахали поинтеры, логика погрязает в куче переводов с курсора в структуры -если вызывает Си, то еще одна технология Лично я за скл, пл/скл, и внешняя жава. Но каждый проект имеет свои особенности, так что где-то про-си хорошо, а где - плохо. ЙЙ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2003, 18:27 |
|
||
|
ProC pro & contra
|
|||
|---|---|---|---|
|
#18+
Главно, как я понял. это "быстро". Быстро? А насколько быстрее ,чем ADO в С++ & и весь СУБД код в stored procedure. На больших селектах, например. Какой оверхед по времени дают надстройки? Кто-нить тесты проводил? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2003, 18:45 |
|
||
|
ProC pro & contra
|
|||
|---|---|---|---|
|
#18+
nebolshoe razmishlenie kak pisat dlia oracle (esli tolko dlia nego): -- esly choto mogesh sdelat na sql (bez problem s perfomance) delay, esli net -- sdelay eto na pl/sql, esli nevozmogno, -- sdelay eto na dinamicheskom sql, egeli nikak -- sdelay eto na oci/proC kak external function, egeli sovsem ne povezlo -- sdelay eto na vstroennoy java stored procedures -- vo vseh ostalnis sluchayah nado smenit ili arhitecturu ili professiu a na kliente (nevagno web server, application server, prosto CS klient) obrabotli mnogo delat ne stoit. eto escho odno pravilo: chem blige k dannim tem proizvoditelnee (taskaniya dannih po setkam net) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2003, 19:14 |
|
||
|
ProC pro & contra
|
|||
|---|---|---|---|
|
#18+
Ну, вопрос-то касался толко ProC. Но за сводку методов - спасибо. Хотя способ обрашения к серверу (ProC, OCI или что еще) не связан с местом выполнения и формированием кода. Можно из ProC на клиенте вызвать сторед процедуру, а можно и весть код процедуры на ProC-клиенте написать. В обоих случаях будет ProC, но второй способ, конечно, менее эффективный. А можно клиента на бейсике + сторед процедуры и PRoC проиграет. Меня же интересовали достоинства именно PRoC. Лично я, кроме простоты и отсутствия накладухи на биндинг параметров больше ничего в этом рудиментарном механизме не вижу, но если я ошибаюсь, то хотел бы знать в чем... Дело в том, что я столкнулся с кодом, написанном на PRoC, где в клиенте были зашиты все SQL - инструкции. Мне эта схема непривычна - я тоже считаю (как и большинство, наверное), что код надо располагать как можно ближе к реальному месту обработки. Но для начала, я сравнил производительность оригинального кода с кодом, написанным на ADO. Это был селект из 60000-строчной таблицы. Код на ADO выиграл. Выбирались одинаковое количество колонок, одинаковое количество строк + в АДО выключался префетч. Выигрыш в моем случае был равен 1/3. Кстати, уважаемые, вы не знаете как включить опцию PREFETCH в ProC-коде. В доке описана, а компилер ругается... Главное достоинство этой опции не отсутствии дополнительного сетевого трафика, а выигрыш во времени, который может быть довольно-таки большим (эффект как в скользящем окне в TCP). А на счет смены профессии - это некорректное замечание. Вообще, хотелось бы пожелать нашим программистам,сидящим на форумах (и не только им), больше толерантности, больше сдерженности. Как образец для подражания рекомендую постинг Страуструпа и контент comp.c++.moderated. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2003, 10:24 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=32089394&tid=1992225]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
44ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
33ms |
get tp. blocked users: |
1ms |
| others: | 228ms |
| total: | 338ms |

| 0 / 0 |
