How many sql functions to support? Is all an overkill?
Posted: Thu Feb 15, 2007 1:32 pm
Hey,
I've set up an SQL Factory to use in my framework for an open-source cms I'm (still) recoding, I've got it all setup and it works fine. I'm using an interface to make sure that all SQL classes (be it MySQL, Postgre, SQLite, MsSQL ... ) have the required methods so that scripts don't break if the admin decides to switch from say MySQL to Postgre.
My problem is, how many/which sql functions do I support? Should I make it so every class has to have every mysql function (without the mysql_ perfix, so for example "mysql_connect" would be "connect" in my interface. I'm currently just building up the interface as I go along, here is what I have so far:
It's a small list for now, is adding all the functions an overkill?
Regards,
I've set up an SQL Factory to use in my framework for an open-source cms I'm (still) recoding, I've got it all setup and it works fine. I'm using an interface to make sure that all SQL classes (be it MySQL, Postgre, SQLite, MsSQL ... ) have the required methods so that scripts don't break if the admin decides to switch from say MySQL to Postgre.
My problem is, how many/which sql functions do I support? Should I make it so every class has to have every mysql function (without the mysql_ perfix, so for example "mysql_connect" would be "connect" in my interface. I'm currently just building up the interface as I go along, here is what I have so far:
Code: Select all
// ---
// iSql is the interface that _all_ SQL classes _must_ implement to make sure that
// there is no missing methods that could potential break a script from switching
// from MySQL to say Postgre.
//---
interface iSql {
public function connect( $host, $user, $pass, $database );
public function smart_clean( $value );
public function query( $query, $output=false );
public function fetch_array( $result );
public function num_rows( $result );
}Regards,