Re:

mathprof@bigfoot.com wrote: > > Thanks again to everyone for welcoming me to this list. I've only got 1c for you this time as The Clown has answered all your other questions. > *Philosophically speaking, is my approach valid? Should I be using a > completely different and unrelated approach? I've seen some discussion > that a database should be used to STORE data, and that a secondary > application program should be used to MANIPULATE data. I like the > unified approach of having the database do everything, because the > database knows a lot more about its own data than an external program. I would modify that definition only slightly by saying the database should be used to maintain a consistent set of data. This means the database should implement your business rules for you. Maintaining your business rules does constitute manipulating your data, but not at the same level as your application. I would avoid stored procedures that merely replicate SQL commands. If you need to apply business rules for a particular SQL statement then use a SP, but otherwise it is a waste of space and resource. I've worked on a system where every single SQL command was implemented through a SP. They had over 600 SPs most of which required exactly the same parameters as the associated SQL command. Don't do this! Cheers, -- Mark. +----------------------------------------------------------+-----------+ |Mark D. Stock - Informix SA http://www.informix.com |//////// /| |mailto:mdstock@informix.com http://www.informix.com/idn |///// / //| |http://www.iiug.org +-----------------------------------+//// / ///| | Tel: +27 11 807 0313 |If it's slow, the users complain. |/// / ////| | Fax: +27 838250 2325 |If it's fast, the users keep quiet.|// / /////| |Cell: +27 83 250 2325 |Therefore, "No news: travels fast"!|/ ////////| +----------------------+-----------------------------------+-----------+