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

[Carl Olsen]

I'm about ready to try this on my local machine.  I'll do a dump of the
database and import it into my local instance of MySQL 5.  Right now, all of
my tables are InnoDB, except for two new tables I just created using MyISAM
for the full text indexing.

Does Propel care about InnoDB or MyISAM, or does it prefer MyISAM.  How will
it deal with foreign keys and cascading deletes in my InnoDB tables?  Should
I remove the foreign keys and cascading deletes before I run Propel against
the database?

What about the stored procedures I have written?  I'm assuming it will
completely ignore my stored procedures and create its own prepared
statements.

--
Carl Olsen, MCSE
Web Developer, CMS Implementation
Marketing and Communications
Drake University
2507 University Avenue
115 Old Main
Des Moines, Iowa 50311-4505
Phone: 515-271-2986
Fax: 515-271-3798
Carl.Olsen at drake.edu
www.drake.edu


-----Original Message-----
From: ciapug-bounces at cialug.org [mailto:ciapug-bounces at cialug.org] On Behalf
Of Daniel.Juliano at wellsfargo.com
Sent: Monday, July 24, 2006 1:57 PM
To: ciapug at cialug.org
Subject: RE: [ciapug] Re: Re: MySQL 5 Stored Procedures (correction)


>> Daniel.Juliano at wellsfargo.com wrote:
>> [...] Writing such 
>> a component is a one-time effort, you can reuse that 
>> component each time you access a database. Stored 
>> procedures are not the answer, Dynamic SQL is."
>
> Tony wrote:
>
> Which is exactly what Propel gives you.  Dynamic, portable 
> SQL in the form of prepared statements.  In fact, much of 
> your code won't even have SQL embedded in it: [...]

Bingo, that's exactly where the discussion leads.  I was 
explaining an O/R Mapper called ActiveRecord to my co-worker, 
and how it: 

a) cleans the SQL out of your code (just like, don't mix 
your php, html, css, and javascript together - save headaches 
and put them all in their separate places), and

b) executes just as fast (if not faster - read that blog) as 
the stored proc way most Microsoft coders are used to (I used 
to be one)

> Also, I don't agree with the all-or-nothing approach 
> (e.g. either prepared statements or stored procedures).  
> I look at SP's as a tool for performance tuning an 
> application.  

Certainly.  If you've got a five step query that populates 
buffer tables then generates a report off the buffers, you've 
probably far exceeded the bounds of Propel, or even your 
ability to encapsulate sql inside a php file.  This stuff 
should live in the database.

> And I'm sorry about yet more Propel rhetoric...I'm even 
> annoying myself with it.  But it is really worth a good 
> once over for any PHP5 developer.

I second that notion.


_______________________________________________
ciapug mailing list
ciapug at cialug.org
http://cialug.org/mailman/listinfo/ciapug