SCO 507 + MYSQL

[Lerebours, Jose]

Fairlight posted

> 
> At about Thu, Sep 29, 2005 at 05:46:55AM -0400,
> Walter Vaughan blabbed on about:
> > 5.* is going after MS-SQL/Oracle with stored events and triggers
> 
> Weren't they also implementing views in 5.x, or is that 
> slated for 6.x now?
> 
> FWIW, I think stored procedures are a real mixed blessing.  
> On one hand,
> you have resource savings by keeping procedures at the server 
> level and
> eliminating needless communications and more attendant potential fault
> points.  On the other hand, it spreads out your programming 
> so that it's
> not all in one cohesive flow from the client-side application.
> 
> Personally, I would prefer it to be all client-side.  Comms is pretty
> inexpensive unless you need to transfer a LOT of data for an 
> operation.
> But then, you have a choice whether to use stored procedures 
> or not.  I'd
> likely choose "not" about 90%+ of the time.  It just seems so 
> sloppy to
> have half your logic in one place, half in another, if you 
> don't need to.
> They're really something I think should be a last resort for 
> "expensive"
> operations.
> 

You are missing a key added value to using stored procedures
"code reusability".  By having stored procedures, you can have
any application using them thus saving you the time to code the
same thing from application to application.  I am sure you can
appreciate this if you used multiple front-end development tools
or if you had same database structure for a *NIX and a *DOZE based
applications.

Imaging, being able to share these stored procedure with
filePro, .NET, PHP, JSP, ASP, CFML, etc.   What is even better is
that if you do your work right, you will have these procedures
produce datasets and then use the datasets to feed your applications
queries.  So, as you can see, if you look at it from this point of
view, it makes sense to use stored procedures.  You change your
stored procedures and you have effectively changed all of your
applications.

Regards;


Jose Lerebours