[ciapug] Re: Re: MySQL 5 Stored Procedures (correction)

[Carl Olsen]

I put EVERYTHING possible in my databases, but I never use a third party
tool to do it.  I use the SQL Server Enterprise Manager for SQL Server,
SQLyog for MySQL, and linux command line for PostgreSQL.  I guess I just
find this stuff interesting and it works well for what I'm doing.  In regard
to my original question, I have code for PostgreSQL stored procedures that
just returns the value of the inserted ID without having to do two queries.
That's why I was wondering if I was doing something wrong with MySQL.  I
looks like I have to do two queries to do the same thing I can do with
PostgreSQL or SQL Server with one query.

-----Original Message-----
From: ciapug-bounces at cialug.org [mailto:ciapug-bounces at cialug.org] On Behalf
Of Tony Bibbs
Sent: Monday, July 10, 2006 5:36 PM
To: carl-olsen at mchsi.com; ciapug at cialug.org
Subject: Re: [ciapug] Re: Re: MySQL 5 Stored Procedures (correction)

Once upon a time, I use to program with MS tools and the craze back then 
was that all the VB screens did all the CRUD work using SP's.  So 
EVERYTHING went into the database.  While I respected the speed of this, 
I've since concluded the architect, even for those days, was making a 
bad mistake.  By now I'm sure they've either rewritten or ported that 
system and I can only imagine the pain and agony that came with it.

...which may explain the lack of any MSCD's where I work.

--Tony

Carl Olsen wrote:
> I assume you learned this by doing it wrong a few times.  I'll check out
the
> tools.
> 
> Thank you!
> 
> -----Original Message-----
> From: Tony Bibbs [mailto:tony at tonybibbs.com] 
> Sent: Monday, July 10, 2006 4:40 PM
> To: carl-olsen at mchsi.com; ciapug at cialug.org
> Subject: Re: [ciapug] Re: Re: MySQL 5 Stored Procedures (correction)
> 
> Given how popular database portability is, I fail to see the real 
> usefulness of SP's if you really want to maintain portability.  Sure, 
> most abstraction layers allow you to call SP's on the server, but more 
> than not, the crap inside the SP is DBMS specific.  Therefore, my view 
> is that if you are using ADODB, PEAR::DB, Creole or PDO then you should 
> really limit the SP's you want to use.  Here at work we only use SP's as 
> a last resort when we have some serious performance issues...which 
> hardly ever happens.
> 
> To top that off, as soon as you use SQL in your code you run the risk of 
> breaking your portability because many developers fail to write portal 
> SQL.  That's why you have persistence tools like Propel which get aim to 
> limit how much actual SQL the developer has to write (plus it gives you 
> that clean data tier you are after).
> 
> Now, if you are using the native PHP driver (e.g. mysql or mysqli) and 
> you know you'll never change DBMS's, write all the SP's you want.  Just 
> my take...
> 
> --Tony
> 
> Carl Olsen wrote:
>> I got quite a lot of criticism from my coworkers at my last job for
trying
>> new things.  Obviously, you don't need an end loader when a shovel will
do
>> the job, so maybe it was fair criticism.  To solve the problem, I moved
on
>> to a new position.  I can understand a company that produces a lot of web
>> sites wanting to keep things simple.  I love programming and I'm always
>> trying the latest tools and programming techniques.  I like the way that
>> stored procedures and prepared statements handle data.  I much prefer to
>> write a data tier that separates my data layer from my presentation
layer.
>> Once I have parameterized functions, I can change the data layer without
>> changing any of the pages that use the functions.  Not everyone is
>> interested in rapidly moving to new technologies (particularly a company
>> that already has a large body of legacy code), but those of who are
should
>> be entitled to our opinions.  I'm in a situation now where I don't have
> any
>> legacy code to deal with.  I'm creating it all from scratch, so I'm
laying
> a
>> foundation that will be easy for me to work with in the future.
> 
> _______________________________________________
> ciapug mailing list
> ciapug at cialug.org
> http://cialug.org/mailman/listinfo/ciapug
_______________________________________________
ciapug mailing list
ciapug at cialug.org
http://cialug.org/mailman/listinfo/ciapug