Alex__kKandrsam,

других-то альтернатив все равно нет...

Альтернатив много.
Непонятно зачем делать из БД комбайн.

Есть штатные средства ОС.
Ими удобнее делать периодические задачи.
Зачем это Г в БД?!

Alex__kKmad_nazgul,

Ну и какие имеются альтернативы, кроме средств ОС?

Любой сторонний шедулер.

p2.mad_nazgulНепонятно зачем делать из БД комбайн.Чтобы не делать комбайн из разработчика, когда он помимо postgres должен знать cron, windows scheduler и как корректно настроить на разных платформах авторизацию, чтобы при смене пароля в БД вдруг не оказалось, что перестали работать джобы.

Причем тут периодичные задания и разработчик?!
Это ни разу не его работа.
Это работа администратора.
Который настраивает задания и периодичность, вплоть до секунды.
Ну и соответственно решает проблемы с авторизацией и пр.

А разработчика не желательно привлекать к задачам администрирования.
У них "мозг" под другое заточен.
Разработчик скорее создаст свой костыльный велосипед, чем решит проблему с помощью стандартных средств.
:-)

Alex__kKmad_nazgul,

а если логика приложения построена на джобах? и джобы должны запускаться в зависимости от каких-то событий в БД? Тут уже одним администратором не отделаешься. А если таких систем не одна а сотни....

В зависимости от каких событий в БД?!
Если все события в БД могут описаны ч/з SQL, то на соответствующие таблицы могут быть навешаны, например, триггеры.
Если нет... То это уже не проблема программиста, а проблема DBA. ;-)

Вот зачем тут Job-ы не понятно.

p2.У каждого свои представления о распределении обязанностей.
То, что СУБД что-то не позволяет разработчику, а он не сует нос дальше SQL, это отнюдь не означает, что результат получится надежным, эффективным и обойдется дешевле.


Э-э-э как бы законы Мерфи нам намекают, что чем проще система, тем меньше ошибок в ней.
Сложная система с кучей состояний дает бесконечное число ошибок.

Смотрел один доклад, в котором докладчик рассказывал про сложность работы с датами.
Например, не факт, что после 31 декабря будет 1 января. Вполне может оказаться и 9 января.
Ну "погасили" сервера перед праздничными каникулами.

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

p2.Это дополнительные коммуникации с еще и админом в процессе принятия архитектурных решений, разработки и дополнительные манипуляции при деплое и сопровождении.


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

p2.Если система эксплуатируется на множестве площадок множества заказчиков, любые дополнительные компоненты аыливаются в множество часов поддержки.

Опять же принцип "разделяй и властвуй".
Вместо того, чтобы разделить задачу на более простые подзадачи.
Программист пишет скрипты, которые надо выполнить, а администратор определяет сам когда они будут выполнены и ч/з какой удобный для него инструмент.
Мы предлагаем внедрить "комбайн", который типа может все.
А потом админу учить каждый новый костыльный велосипед, который приумал разработчик и/или вендор, чтобы периодичные оттюнинговать время выполнения и продолжительность выполнения скриптов, т.к. они могут намертов вешать систему в самый отвеnственный момент. :-)

Alex__kKТриггерами не всегда обойдешься. Например, в БД лежат какие-то сущности, есть какая-то сессия, которая добавляет в БД эти сущности и следит за их состоянием, так вот, например, при переходе сущности из одного состояния в другое, необходимо запустить какую-то обработку, которая занимает какое-то ощутимое время. Если мы запускаем эту обработку в этой сессии, которая следит за состоянием сущностей (напрямую или через триггеры), то эта сессия и будет как раз и выполнять данную обработку и соответственно тормозиться, пока не пройдет обработка. Вместо этого мы из данной сессии создаем и запускаем джоб, в котором запускаем обработку (асинхронно), а сессия, которая обрабатывает статусы сущностей пашет дальше и не тормозится.

Так это к крону вообще никакого отношения не имеет.
Да и к БД тоже.
Вы описали, то что должен делать сервер приложений, т.е. это бизнес-логика.
Изменение состояния сущностей.
Причем как и что, по мне, удобнее вынести в более подходящий ЯП.
Чем городить фрянкинпуха.

Я по этому и против "создания" комбайнов.
Но вендорам это очень нравиться.
Т.к. вендор лок и никуда ты не денешься.
Переход на другие решения это страдания и боль.
Посмотрите "истории успеха" перехода с одной БД на другую.
Хотя все вроде бы стандарты SQL блюдут :-)

p2.Внешние джобы дополнительный компонент с отдельным интерфейсом. Сложность +1.


Нет сложность остается та же самая.
Просто перераспределяется по другому.
Где-то ушло, куда-то пришло ;-)

p2.в очередной раз примеряешь отсутствие встроенного в СУБД стандартного инструмента на частную организацию труда. В оракле не требуется "велосипед". Программист пишет "создать джоб" с требуемым расписанием или для асинхронного выполнения по событию. Ему не требуется тратить время на пересказывание требований админу. Не требуется запрашивать и ждать логи ОС или сидеть вместе и пялиться в логи ОС, когда джоб не сработал. Не требуется оговаривать, что в этом релизе, помимо sql-скрипта, нужно еще сделать то-то и то-то. Не требуется договариваться с админом во время разового массового обновления на короткое время отключить мешающий этому обновлению джоб.


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

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


Так они ни куда не денутся. Просто вылезут на продакшене, когда база ляжет. :-)

p2.Да-да. Разделим написание программ между сто одним кодером, где каждый умеет нажимать определенную клавишу, но зато очень быстро! Вот только сколько времени уйдет на это разделение и синхронизацию выполнения...

А кто сказал, что будет легко?!
Понятно, что проще кодит один Got-object.
Но это write-onle-way.
Таки делить систему на простые подсистемы и выносить сложность на более высокий уровень абстракции, это как бы стандартный способ построения крупных систем. :-)