Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

(z) Re^2: Separation of SQL code

by zigdon (Deacon)
on Sep 11, 2003 at 15:17 UTC ( #290712=note: print w/replies, xml ) Need Help??


in reply to Re: (z) Separation of SQL code
in thread (z) Separation of SQL code

I believe that's not an option in MySQL? And this project probably can't use anything else, due to technical and budget constraints.

-- zigdon

Replies are listed 'Best First'.
Re: (z) Re^2: Separation of SQL code
by mikeB (Friar) on Sep 12, 2003 at 15:20 UTC
    Have you looked at PostgreSQL? It's also free (as in beer) and supports stored procedures in a number of languages, including Perl, and apparently works nicely with PHP as well.

    There are a number of visual DBA tools available for it (some also free) which make it pretty easy to use.

    I've been using the Eclipse IDE lately, and like the Eclipse plugin, Quantum, which extends the basic IDE to allow working with most databases that provide JDBC support.

    - mikeB

Re: Separation of SQL code
by Abigail-II (Bishop) on Sep 11, 2003 at 15:23 UTC
    Oh, your question suggested you were working on a serious project. MySQL is a feature-poor database that I can't take seriously.

    Abigail

      I can't take seriously anyone who'd suggest putting everything into stored procedures. Calling a stored proc for a simple select is often more expensive than executing it on its own, and procs should typically not be called from loop constructs or other stored procs due to the decision making the DBMS needs to perform on each procedure call. Sure, your code may look a bit simpler, but your DB might not be so happy.

        The idea is to abstract the business logic off to the stored procedures, so you'll be unlikely to be doing just a simple select.

        Indeed, keeping everything the side of the database more often speeds things up in my experience. You're not moving data over the wire so all processing is happening locally. For example, doing anything involving iterating over a set of rows is likely to be a lot faster if you keep everything on the database side. It's also common to have more CPU cycles to play with on the database server too.

        So I guess my experience is the opposite of yours :-)

        This isn't to say I always think stored procedures are a good idea.

        They are highly database dependant for example. If you're dealing with multiple databases, or if its possible you'll want to switch platforms, stored procedures are probably a bad idea.

        Also, if you're only developing a single application then many of the safety advantages in isolating the business logic in the database disappear. An API in one language is just as good as an API in another. In this case it can make sense to keep everything in a single language so you don't have to find a PL/SQL (or whatever) coder for the team.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://290712]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (4)
As of 2022-05-27 21:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you prefer to work remotely?



    Results (97 votes). Check out past polls.

    Notices?