> There's nothing wrong with polling as long as it's
> moderate and it doesn't lock resources.
> On a heavily updated table in a large volumen site, it
> scales much better than nasty triggers or events
> firing all over the place.
> Triggers are intended to maintain internal database
> consistency by enforcing business rules at the DB
> tier. They're not meant for event notification of
> external applications, especially if you're holding
> the transaction hostage until the remote call is
Enforcing business rules? If you can put your rules
into constraints, do it and drop the triggers.
Triggers can be used for anything you like. Firing
events can be one of them.
> As someone mentioned here, asynchronous events
> (fire'n'forget) in some DBMS systems are much better
> suited to this because they don't don't prolong
> transactions, and subsequently locks on resources.
> I think the best choice in your scenario is to use
> adaptive polling: Track the average of DELTA (new
> records added between polls) over time, and adjust the
> polling internval accordingly.
> For example, if the current average DELTA is 100, and
> the new DELTA was 120, then you decrease the polling
> interval proportionally but not less than MIN value,
> and if it was 80, then you increase the polling
> interval proportionally but not greater than MAX
This sounds like usuable advice.
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL