Thanks to all. Simon's response outlines the direction I will be headed. KC
[snip] The argument usually used by people looking for - triggers - functions + procedures - foriegn keys is the persuit of data integrity, and encapsulating business logic within the database. Whilst this goal is noble, it can be fully achieved within the application code, and not in the database. Having this functionality within the application has the following advantages - database design is simpler - database load is lower - fewer locking problems - testing data at application level is cleaner and more efficent than at the database. Any argument that implementing the implementing business logic ONCE at this database is more efficient ignores the use of 3GL libraries. I have worked on many projects with Oracle and MySQL, and I have always found implmenting business logic within the application more efficient. This does not mean triggers and procedures where not used, but complicating business logic that might cause a cascade of updates, inserts and deletes from many sources is always problematic. As MySQL stands now, I would recommend running a daemon process, written in Perl (or other language), that could process new data. This has the advantage of being future proof, and eliminates the potential problems that triggers cause due to data inserts from multiple sources. Simple create two table sets, one for loading data, and one for processed data. Have a perl daemon scan the load tables every 30s and process the data accordingly. [/snip] Much applause for your statements here Simon! It also makes the applications much more portable. Well said. Jay -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
