Re: [chiPHPug-discuss] DB Class workflow question

[Jason R. <ja...@ho...>]

As a potential counter to the prepared statement path, one problem is 
that mysqli precludes persistent connections.

In certain large scale architectures persistent connections have a big 
benefit.  In the hands of developers that dont understand the entire 
system architecture and/or don't have control over all aspects of it 
(any shared hosting environment for example), prepared statements can be 
harmful.

Precluding their use just for data input validation is throwing out a 
useful tool in the scaling toolbox that you may need in the future. 
That matters only if their is a possibility that you will need massive 
scale in this DB handler.

One approach that I suggest is keeping user input validation near its 
input handler and keeping DB protection minimal (i.e. something like 
escape).

The reason being that you want both business logic validation (i.e. 
email address can't be NULL here) and data field validation (email 
address can't contain the '#' char) to be handled consistently and 
leverage any common user error dialogs or exception handling routines 
correctly.  This is squarely in the user-facing application logic 
portion and not in your data persistence layer (unless you are an Orcale 
monkey and then half your app logic is in your stored procedures and 
triggers).





Neil Young wrote:
> I think prepared statements are the best way to go, assuming that Walter is
> using MySQL.  Walter, if you are using another database that doesn't support
> prepared statements, such as MS SQL Server, then my approach would be to
> minimally do data type validation on step 3 - this is also a location that
> you could ensure other kinds of data integrity if you so choose.
> 
> Neil
> 
> -----Original Message-----
> From: chi...@li...
> [mailto:chi...@li...] On Behalf Of Larry
> Garfield
> Sent: Thursday, October 04, 2007 12:28 AM
> To: chi...@li...
> Subject: Re: [chiPHPug-discuss] DB Class workflow question
> 
> Enter the magic of prepared statements.  I personally prefer to use PDO,
> since 
> I like it's interface better than MySQLi's and it supports both named and 
> unnamed parameters.
> 
> http://www.php.net/pdo
> 
> It requires PHP 5.1 or later.  If you're using an earlier version of PHP,
> you 
> need to be smacked because anything older than that is dead and the funeral 
> is in process:
> 
> http://gophp5.org/
> http://www.php.net/index.php#2007-07-13-1
> 
> Note that if you're using a database other than MySQL, you'll run into some 
> field types that still need special handling.  Most notable is LOBs in
> Oracle 
> and DB2, since those databases still think it's 1988.
> 
> On Wednesday 03 October 2007, jsWalter wrote:
>> I'm rolling my own little DB class (pls, I don't need to hear about how
>> wonder this or that class is, thank you, I've reading over 2 dozen such
>> libaries) and I have a question to this group...
>>
>> Workflow:
>>  1) submit data form
>>  2) pull data from POST
>>  3) "clean" data
>>  4) update record
>>
>> Now, my question deals with step 3.
>>
>> On one hand, the cleansing of the data needs to be done by the developer.
>>
>> On the other, would it be logical for the DB class to take a whack at the
>> data set and to make sure each field is the data type that the database is
>> expecting? Or should the developer code that as well?
>>
>> Ideas?
>>
>> walter
>>
>>
>>
>>
>> ====================================================
>> Taking it to the next level.
>>    web.torres.ws/dev/php/walters_way
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> chiPHPug-discuss mailing list
>> chi...@li...
>> https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss
> 
>