 |
 |
Archives of the TeradataForum
Message Posted: Mon, 21 Nov 2005 @ 21:00:08 GMT
| Subj: | | Re: Stored Procedures Results |
| |
| From: | | McBrideM |
I appreciate your thoughtful response. I would like to, however, make one further post regarding one thing you said:
| | Option#1 is the ONLY choice in my opinion. The best place to enforce the business rules depicted by a data model is best served by
business processes that are in close proximity to the application interface, but are easy to document, maintain, remain portable and can be manage
under configuration management tools (i.e., are visible). SPs and Macros do not fit that bill very well. | |
I'm not sure I see the difference, in the end, of how you "program" a business rule? Whether you use C++ and write your 'methods' or COBOL and
write a procedure, or Use SPL (Store Procedure Language), you're still accomplishing the same thing, the implementation of business rules using an
application (code). SP's are just another tool in the toolbox of the programmer/analyst. I have always strived to look for the best tool for the
job...consider picking out a hammer for a specific nail, there is a variety to choose from, roofing hammers are not exactly the same as a framing
hammer or a finishing hammer, so one must always seek to match the job with the tool. I wouldn't want to use a 20 pound sledge hammer to drive an
8p finishing nail into my nice base trim floor molding. That being said, some things are more like the 'half dozen of one vs. six of another' so
it might not make a difference. But I digress, if the point your trying to make is that SP's cannot be managed under change control, I fail to
understand. Just as the source code for a C++ or JAVA program can be managed, so too, can SP code. You can 'lock down' the source code and not
allow changes to the compiled SP in the same fashion as you do with any other programming language. The database itself is just as much under
change control as the applications that support it. In my opinion, Change Control and Change Management is a process and not just a way to manage
programming 'objects'.
In any case, I make no argument in favor or against Stored Procedures. Personally I don't even use them, but I will say that I'm never in
favor of eliminating or restricting the use of any performance enhancing tool that may be available today. Designer/Architects need every weapon
available in their arsenal from which to attack today's diverse and challenging data 'opportunities'. Stored Procedures are just another
programming tool to aide us in that quest.
Thanks for the opportunity to offer an opinion, and I respect your point of view as well!
Michael E. McBride, MSCIS
| |
