Re: Re: N-tier, client/model, and business rules?

First off, I agree. Having a decent set of stored procs can really simplify migration and changing situations, a stored proc might even return results from a totally different DB than the one the user is connected to. But I was wondering about one thing, I am a Sybase user, iirc you are as well. Ive noticed that a heavy use of stored procs is favoured by Sybase users. Since I've not had much exposure to other DB's I cant really say, but I have noticed that it seems users of other DB's tend not to go that way. Any thoughts from your point of view?

---
demerphq

_{<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...}

Comment on Re: Re: N-tier, client/model, and business rules? Download Code

Replies are listed 'Best First'.

Re: Re: Re: N-tier, client/model, and business rules?
by pfaut (Priest) on May 15, 2003 at 20:32 UTC

I've used Oracle, PostgreSQL and SQL Server. I push as much as possible into stored procedures on all of these platforms. It saves a lot of data moving back and forth between the program and the database. Oracle and PostgreSQL have very powerful procedural languages that can be used to write stored procedures (PostgreSQL stored procedures can even be written in perl). SQL Server seems a little weaker in this regard but seems to be getting better in newer versions.

90% of every Perl application is already written. ⇒

dragonchild

[reply]

Re: N-tier, client/model, and business rules?
by Abigail-II (Bishop) on May 15, 2003 at 19:52 UTC

AFAIK, Oracle has stored procedures as well. I've done some db2 work, but that was mostly writing an qmail-db2 interface (in C); I don't know whether db2 has stored procedures.