(yet another) DB Class...

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
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...

 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

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?



Re: (yet another) DB Class...

On Thu, 04 Oct 2007 06:29:04 +0200, otrWalter@gmail.com  

Quoted text here. Click to load it

Ideally it works with prepared statements, where the number/string  
distinction is allready taken care of. There may be other requirements on  
data however (a phone number or postal code should be valid, some number  
has a min or max), which your database should know nothing about, and  
shouldn't try to provide usefull error messages for the user. That really  
is something up to the code using the database.
Rik Wasmus

Re: (yet another) DB Class...

Quoted text here. Click to load it

There's one set of cleansing things you always have to do to, for example,  
prevent SQL injection.
But then there's always a business logic step - where you gotta make the  
data conform to some adminsitrative rule.

So what I do is have my database class  
(http://www.kaufman.net/bvckvs/bvckvs_database.php.txt ) do the SQL injection  
prevention stuff.
But then, I use that abstract class to EXTEND another class - which does the  
business logic.

Three tier is my rule-of-thumb - database, business logic, user interface.

Site Timeline