I have just ported my CRiMson (CRM) system to this type of idea last night!
Very simple actually, and mebbe this is to simple for your needs, but I
wanted my project to be portable, plus it was a proof of concept idea for me
to see if this is feasible going forward. So far I'm very happy with the
results... All I did was create a "db.php" include file, put that at the top
of any page requiring the db access, and use my custom SQL_ calls. Now,
should I ever change the RDBMS backend, I (in theory) only need to change
this page. Plus, my code is much cleaner. I see this expanding as I use more
features, but honestly, these are the only 4 functions that I ever use in
mySQL/PHP anyways...
<?php
$db = mysql_connect ("localhost","user","pw") or die ("Could not connect to
SQL server.");
mysql_select_db ("crm",$db) or die ("Could not select CRM Database");
function SQL_QUERY($sql)
{
global $db;
//echo $sql."<BR>";
$result = mysql_query($sql,$db);
if (!$result)
{
global $errorString;
$errorString .= "<FONT CLASS='error'>Error ::
".mysql_errno($db)." :: ".mysql_error($db)."<BR>".$sql."<BR></FONT>\n";
}
return $result;
}
function SQL_NUM_ROWS($result)
{
return mysql_num_rows($result);
}
function SQL_ASSOC_ARRAY($result)
{
return mysql_fetch_array($result,MYSQL_ASSOC);
}
function SQL_INSERT_ID()
{
return mysql_insert_id($db);
}
?>
> -----Original Message-----
> From: Scott Winkle [mailto:swinkle@wittenberg.edu]
> Sent: Friday, April 25, 2003 8:19 AM
> To: php-db@lists.php.net
> Subject: PHP Database Abstraction...
>
>
> Hi all,
>
> Looking to get opinions here.
>
> I have begun a fairly major project which I do not want to
> give too many
> details out on right now, but one of the major goals is
> abstraction for
> all major SQL databases. Of course, MySQL is the most
> important and also
> the only one I have any significant experience with.
>
> Previous, non-public projects (this will eventually be an open-source
> project once I have it ready for prime time and secure a few
> commercial
> sales) I have used my own system of abstraction, basically having a
> class for each database type and changing the include as needed, that
> class had methods for all major queries so most SQL was part of that
> class, and others who were familiar with the different databases made
> the classes as needed for the other databases. So far, it has
> seemed to
> work well, given that the projects that used this method only
> ran code
> developed as part of the core project. 'Mods' and 'Plugins' were at
> users own risk.
>
> This project, which some might classify as a YAPS (Yet Another Portal
> System) -- even though there are numerous core differences --
> will have
> modules, add-ons, and plugins all handled structurally as part of the
> core, requiring a good DB Abstraction API.
>
> I have thought about PEAR, AdoDB, dbx, etc, but my thinking is that
> might make it harder for the users (site admins) to develop their own
> database module as needed...
>
> Has anyone had experience with doing this or can provide good
> feedback/opinions on what would work best?
> The three options I am considering are: Custom Abstraction
> (Similiar to
> what I have done before, but fixed up a bit to support custom code),
> dbx, and PEAR. I have seen enough benchmarks to rule out
> AdoDB at this time.
>
> Thanks,
> Scott
>
>
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
