The only advantage would be that an in-database solution would be OS
independent and it could be managed using the same tools which manage
the database itself, including the backup and management of it. I'm not
sure how the Oracle thing is working, but I suppose you can manage it
using plain SQL. This makes for a more homogeneous solution.
Using cron makes your database solution OS dependent, and if you want to
programatically manage the tasks, then your program will be also OS
dependent.
This is about the advantages I can see of an integrated scheduling
service. That said, you can always shift that in your middle-tier (if
you have a 3 tier system), possibly backed by some DB tables (this is
how we do our scheduling here).
Cheers,
Csaba.
On Thu, 2004-12-16 at 10:12, Marco Colombo wrote:
> On Wed, 15 Dec 2004, Jim C. Nasby wrote:
>
> > No, PostgreSQL doesn't have an equivalent to Oracle's dbms_job, but this
> > is a question that comes up pretty often. I think the bulk of the work
> > to make this happen could be done outside of the core database, so it
> > seems a good candidate for pgfoundry.
>
> What's wrong with at, cron, and some trivial shell scripting?
> (This is a real question, I wonder what advantages dbms_job has.)
>
> .TM.