<html>
<!-- BEGIN WEBMAIL STATIONERY -->
<head></head>
<body>
<!-- WEBMAIL STATIONERY noneset -->
<DIV></DIV>
<P>Fortunately, I've never used stored procedures to do mathematical calculations. I've always used a programming language to do calculations, probably because the books I read do it that way. At least now I can understand why they do it that way. I started using stored procedures because I read somewhere that you can avoid SQL injection attacks by parameterizing your functions to feed into stored procedure parameters which are strongly typed (meaning the data type that each column in a database table uses). It made sense to me and seemed to be an easy way of keep track of what kind of data you are trying to stuff into a database column. I use stored procedures so that I concentrate on what type of data I'm trying to feed into a database table column.</P>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">-------------- Original message from Tony Bibbs <tony@tonybibbs.com>: -------------- <BR><BR><BR>> Yeah, that's not going to be very useful. Future Propel versions will <BR>> use the PHP PDO implementation and should be a transparent upgrade for <BR>> users (granted PDO is enabled). Obviously the switch to PDO will bring <BR>> significant performance improvements. And, as you pointed out, the <BR>> other ORM offerings have probably changed. <BR>> <BR>> Fact is, when using an ORM you are typically trading off some <BR>> performance for flexibility. Now, aside from using some fairly standard <BR>> coding guidelines, I personally don't worry about performance until <BR>> performance is an issue. That may sound a bit short sighted but my <BR>> point is that a lot of tuning can happen after you take you stab at <BR>> coding. We use APC (which requires you to
adjust some of you coding <BR>> standards for maximum benefit) and if we find Propel is a dog in some <BR>> places we either swap it out for custom SQL or we build an SP to do the <BR>> heavy lifting. We'll also use tools like http_load and, if needed, <BR>> callgrind to help identify areas where performance can be improved. <BR>> <BR>> However, for normal CRUD stuff, you shouldn't need to worry about <BR>> performance. <BR>> <BR>> --Tony <BR></BLOCKQUOTE>
<!-- END WEBMAIL STATIONERY -->
</body>
</html>