ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Портирование из Oracle
16 сообщений из 16, страница 1 из 1
Портирование из Oracle
    #39394430
paulman2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
paulman2
Гость
Помогите закоренелому ораклисту понять идеологию PG.

В Оракле в джобе был простой код типа:

begin
for cur in (
select * from mytable --записи в таблице независимые
)
loop
begin
--действия по изменению записи в связанных таблицах по ключу
commit;
exception
when others then
--запись в лог в автономной транзакции
rollback;
end;
end loop;
end;

Как можно что то аналогичное сделать в PG без commit и автономных транзакций?
Глобальная задача - взять из курсора кучу строк и обработать их - если на какой то получили ошибку - и ладно - записали в лог и пошли дальше. Строки независимы - требуется как можно раньше сделать результат доступным для других сессий.
...
Рейтинг: 0 / 0
30.01.2017, 10:54
| Ответить | Цитировать | Написать  
Портирование из Oracle
    #39394466
p2.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
p2.
Участник
paulman2,

поскольку внутреннего шеделера нет, то и переживания по вопросу транзакций из внешнего инструмента не должны усугублять когнитивный диссонанс.
...
Рейтинг: 0 / 0
30.01.2017, 11:26
| Ответить | Цитировать | Написать  
Портирование из Oracle
    #39394471
paulman2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
paulman2
Гость
p2.,

запускаю например через PostgreSQL Scheduling Agent - pgAgent
...
Рейтинг: 0 / 0
30.01.2017, 11:33
| Ответить | Цитировать | Написать  
Портирование из Oracle
    #39394483
paulman2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
paulman2
Гость
или предлагается свой шедулер писать?
...
Рейтинг: 0 / 0
30.01.2017, 11:43
| Ответить | Цитировать | Написать  
Портирование из Oracle
    #39394537
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
paulman2p2.,

запускаю например через PostgreSQL Scheduling Agent - pgAgent
в пж есть встроенный в пж клиент к пж.

CREATE EXTENSION /*IF NOT EXISTS*/ dblink;

https://www.postgresql.org/docs/9.6/static/dblink.html
...
Рейтинг: 0 / 0
30.01.2017, 12:47
| Ответить | Цитировать | Написать  
Портирование из Oracle
    #39394538
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
paulman2или предлагается свой шедулер писать?лучше бы написать, чем пжогент.

своего воркера, наверное.
...
Рейтинг: 0 / 0
30.01.2017, 12:48
| Ответить | Цитировать | Написать  
Портирование из Oracle
    #39394677
Alex__kK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex__kK
Участник
paulman2,

Нужно делать все через автономки, автономки в пг эмулируюся через dblink.
...
Рейтинг: 0 / 0
30.01.2017, 14:23
| Ответить | Цитировать | Написать  
Портирование из Oracle
    #39394736
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mad_nazgul
Участник
paulman2или предлагается свой шедулер писать?

Здесь вам не тут.
Все удобства во дворе.

А так шедулер писать не надо.
Есть cron, например.
Я бы вынес всю логику в отдельное "приложение", которое бы запускал по cron'у.
<:o)
...
Рейтинг: 0 / 0
30.01.2017, 15:02
| Ответить | Цитировать | Написать  
Портирование из Oracle
    #39394791
paulman2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
paulman2
Гость
mad_nazgul,

Я правильно понимаю что на PL/PGSQL логику вообще писать не рекомендуете ввиду его убогости и тормознутости?
...
Рейтинг: 0 / 0
30.01.2017, 15:39
| Ответить | Цитировать | Написать  
Портирование из Oracle
    #39394823
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
paulman2mad_nazgul,

Я правильно понимаю что на PL/PGSQL логику вообще писать не рекомендуете ввиду его убогости и тормознутости?

Я не могу сказать что pl/pgsql чем то кроме отсутствия автономных транзакций принципиально уступает оракловому pl/sql.
На нем вполне можно сложную логику писать (хотя отлаживать ее конечно удовольствие еще то).
И работать оно будет скорее всего быстрее чем тоже самое сделанное на клиенте (за счет отсутствия network обмена при работе).


--
Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
30.01.2017, 16:16
| Ответить | Цитировать | Написать  
Портирование из Oracle
    #39394938
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
paulman2mad_nazgul,

Я правильно понимаю что на PL/PGSQL логику вообще писать не рекомендуете ввиду его убогости и тормознутости?
неправильно

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

 
про сложность отладки -- брехня. но когда пишешь из середины во все стороны, не имея готовой концепции -- иногда таки можно в конечностях запутаться. важно знать, что ддл, в том числе создание /пересоздание ф--й -- транзакционно, но (пере)закоммиченная кем либо ф--я будет исполняться даже в рипитбл рид транзакции, стартовавшей до коммита нового тела ф--ии (как если бы уровень изоляции был рид коммитед). т.е. тут есть место , где можно словить нежданчика, если злоупотреблять обновлением телес ф--ий без остановки юзеров/джобов.
...
Рейтинг: 0 / 0
30.01.2017, 18:05
| Ответить | Цитировать | Написать  
Портирование из Oracle
    #39395099
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mad_nazgul
Участник
paulman2mad_nazgul,

Я правильно понимаю что на PL/PGSQL логику вообще писать не рекомендуете ввиду его убогости и тормознутости?

На императивном ЯП вообще в БД писать не нужно.
Для этого есть более удобные инструменты.
<:o)
...
Рейтинг: 0 / 0
31.01.2017, 07:14
| Ответить | Цитировать | Написать  
Портирование из Oracle
    #39395559
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
mad_nazgul,

> На императивном ЯП вообще в БД писать не нужно

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

если вам не нужно, то и не пишите.


"контур" БД -- вещь крайне условная, и для точки деплоя кода (насколько близко к данным и транзакциям) есть очень много условий
...
Рейтинг: 0 / 0
31.01.2017, 15:31
| Ответить | Цитировать | Написать  
Портирование из Oracle
    #39395618
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mad_nazgul
Участник
Misha Tyurinmad_nazgul,

> На императивном ЯП вообще в БД писать не нужно

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

если вам не нужно, то и не пишите.


Так ведь и не пишу.
Просто иногда приходится разгребать дерьмо, за теми кто пишет.

Misha Tyurin"контур" БД -- вещь крайне условная, и для точки деплоя кода (насколько близко к данным и транзакциям) есть очень много условий

В современных СУРБД основным является ДЕКЛАРАТИВНЫЙ ЯП SQL.
Под него заточена оптимизация, транзакции и пр.

Императивные расширения в БД это "костыль".
Данный "костыль" нужен из-за того, что РМД (на которой построены все СУРБД) является ограниченной.
А средства интеграции других ЯП с БД были в зачаточном состоянии.
Сейчас с этим гораздо лучше.

Так вот зачем пользоваться "костылем", когда есть другие более удобные "инструменты" (ИМПЕРАТИВНЫЕ ЯП)

Не говоря уже о всяких модных сейчас функциональных ЯП.

Вы и их предлагаете внедрить в БД?

Поэтому, по мне, ХП нужно пользоваться только в крайних случаях, когда реально без них нельзя.
...
Рейтинг: 0 / 0
31.01.2017, 16:05
| Ответить | Цитировать | Написать  
Портирование из Oracle
    #39444966
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
mad_nazgul
В современных СУРБД основным является ДЕКЛАРАТИВНЫЙ ЯП SQL.
Под него заточена оптимизация, транзакции и пр.
Императивные расширения в БД это "костыль".
Данный "костыль" нужен из-за того, что РМД (на которой построены все СУРБД) является ограниченной.
А средства интеграции других ЯП с БД были в зачаточном состоянии.
Сейчас с этим гораздо лучше.
Так вот зачем пользоваться "костылем", когда есть другие более удобные "инструменты" (ИМПЕРАТИВНЫЕ ЯП)
Не говоря уже о всяких модных сейчас функциональных ЯП.
Вы и их предлагаете внедрить в БД?
Поэтому, по мне, ХП нужно пользоваться только в крайних случаях, когда реально без них нельзя.
Это у вас какое-то религиозное представление о СУБД.
У меня было полно отчётов, которые, мягко говоря, не оптимально выполнять одним селектом.
А в паре случаев - невозможно реализовать. Да и незачем.
Кому что удобно применительно к задаче - тот тем и пользуется.
...
Рейтинг: 0 / 0
26.04.2017, 18:36
| Ответить | Цитировать | Написать  
Портирование из Oracle
    #39445533
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mad_nazgul
Участник
ОКТОГЕНЭто у вас какое-то религиозное представление о СУБД.


Не религиозное, а чисто прагматическое.
Т.к. чаще всего ХП это write-only.
Ну и для современных ЯП создано куча удобного инструментария, которые не всегда бывают в актуальных СУРБД.

ОКТОГЕНУ меня было полно отчётов, которые, мягко говоря, не оптимально выполнять одним селектом.
А в паре случаев - невозможно реализовать. Да и незачем.
Кому что удобно применительно к задаче - тот тем и пользуется.

Просто я уже этим накушался еще со времен FoxPro.
Где создаешь запросом курсор, а потом в цикле гуляешь по этому курсору туда-сюда, попутно делая запросы.
Но в FoxPro хотя бы отладка была удобнее.
...
Рейтинг: 0 / 0
27.04.2017, 15:31
| Ответить | Цитировать | Написать  
16 сообщений из 16, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Портирование из Oracle
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&fpage=74&tid=1996548]:
 0ms
get settings:
 9ms
get forum list:
 16ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 30ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 52ms
get tp. blocked users:
 2ms
others: 321ms
total:  448ms
созд. / загр.: 448ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]