> 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 > completed.
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 > value. This sounds like usuable advice. With regards, Martijn Tonies Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL Server Upscene Productions http://www.upscene.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
