Запуск программы по таймеру vs выполнение подпрограммы по ..

[GAMER]

Запуск программы по таймеру vs выполнение подпрограммы по таймеру.

И так, задача:
через определенные промежутки времени нужно считать данные с СУБД, и запустить скрипт (внешний).
Если реализовать на паскале, то что лучше?
1. Через крон (или другой планировщик) запускать через промежутки времени программу, которая подключиться к СУБД отработает и завершит работу.
2. При старте системы запустить программу, которая подключиться к СУБД и через таймер будет запускать подпрограмму с тем же результатом.

Плюсы первого варианта.
1. Не висит в памяти.
2. Если был обрыв сессии с СУБД, то перелогинится сама.

Минусы первого варианта.
1. Каждый раз нужно подключатьсчя к СУБД.

Плюсы второго варианта.
1. Один раз подключился и не дергаем авторизацию СУБД.
2. Не нужно крон или другой планировщик.

Минусы второго варианта.
1. Занимает место в памяти.
2. Если обрыв сессии нужно это проверять.

Дополнительная информация.
1. СУБД - майскл.
2. Промежутки равны 1 минуте.
3. ОС - FreeBSD (и не только).

[Padre_Mortius]

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

[GAMER]

Ограничений нет.

[bw]

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

..bw

[GAMER]

Держать соединение не более красиво чем его постоянно поднимать.

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

[alexs]

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

[KSergey]

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

[Kemet]

GAMER, а сколько времени занимает соединение/разъединение, обработка данных и формирование скрипта и, видимо его выполнение? С учетом, что это должно осуществляться каждую минуту, стоит ли оно, дергать кроном?

[alexey38]

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

[GAMER]

GAMER, а сколько времени занимает соединение/разъединение, обработка данных и формирование скрипта и, видимо его выполнение? С учетом, что это должно осуществляться каждую минуту, стоит ли оно, дергать кроном?

Если СУБД локально, то секунды (а то и меньше).
Вообще, задачу эту решил через перл. Как-то более по опенсорсному
Плюсы:
1. Маленький скрипт - мало места, легко бекапить и переносить.
2. Кроссплатформенность.
3. Видно сорсы скрипта.
4. Другие могут вносить изменения без наличия ФПЦ/Лазаруса.
5. Код попроще.
Но это в даном случае.
Если код посложнее, то может и фпц/лазарус бы более подошел.