Re: Fwd: Fwd: [PHP-DB] MySQLi connections

2008-11-26 Thread Fergus Gibson
On Wed, Nov 26, 2008 at 1:45 PM, Chris <[EMAIL PROTECTED]> wrote:
>> It's bad if you ever want to use something other than mysqli!  Imagine
>> your company switching to another database server.  You'd have to
>> rewrite code in hundreds of functions!
[...]
> You're going to have a lot more problems with changing db servers than just
> search/replac'ing mysqli calls. Eg - 'LIMIT' - the format is different for
> postgres, mssql doesn't have it nor does oracle.

In case it was unclear, that's precisely my point.  Abstraction would
make it much easier to change databases later if need be because all
the SQL could be contained in a class with a simple interface exposed
to the rest of the application.  Switching databases would only
involve making changes to that class then, which is much easier than
trying to update many functions in many different places.  In the
current scheme Mr. Hill describes, each function is tightly coupled to
the database because they all feed SQL to the mysqli class directly.
He asked what's wrong with the scheme, and I think it's fair to say
that's the problem.

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: Fwd: Fwd: [PHP-DB] MySQLi connections

2008-11-26 Thread Chris

Fergus Gibson wrote:

-- Forwarded message --
From: Fergus Gibson <[EMAIL PROTECTED]>
Date: Wed, Nov 26, 2008 at 11:55 AM
Subject: Re: Fwd: [PHP-DB] MySQLi connections
To: "J. Hill" <[EMAIL PROTECTED]>


On Tue, Nov 25, 2008 at 3:12 PM, J. Hill <[EMAIL PROTECTED]> wrote:

I am used to creating a class and a database handle for functions to use,
but I inherited an intranet that just uses a single "$mysqli =
mysqli_connect " in a global main file and the just uses "global
$mysqli" in all of it's functions (several hundred) that interact with the
database.

[...]

Could anyone point me towards any documentation on why such a structure is
bad?


It's bad if you ever want to use something other than mysqli!  Imagine
your company switching to another database server.  You'd have to
rewrite code in hundreds of functions!  This is where a database
wrapper class could have saved a lot of headache.  As it is, the least
expensive way to migrate databases permitted by the original
programmer's choice would be to write an adapter class and substitute
it in place of mysqli and hope there are no SQL incompatibilities.
Not very efficient though.


You're going to have a lot more problems with changing db servers than 
just search/replac'ing mysqli calls. Eg - 'LIMIT' - the format is 
different for postgres, mssql doesn't have it nor does oracle.


--
Postgresql & php tutorials
http://www.designmagick.com/


--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Fwd: Fwd: [PHP-DB] MySQLi connections

2008-11-26 Thread Fergus Gibson
-- Forwarded message --
From: Fergus Gibson <[EMAIL PROTECTED]>
Date: Wed, Nov 26, 2008 at 11:55 AM
Subject: Re: Fwd: [PHP-DB] MySQLi connections
To: "J. Hill" <[EMAIL PROTECTED]>


On Tue, Nov 25, 2008 at 3:12 PM, J. Hill <[EMAIL PROTECTED]> wrote:
> I am used to creating a class and a database handle for functions to use,
> but I inherited an intranet that just uses a single "$mysqli =
> mysqli_connect " in a global main file and the just uses "global
> $mysqli" in all of it's functions (several hundred) that interact with the
> database.
[...]
> Could anyone point me towards any documentation on why such a structure is
> bad?

It's bad if you ever want to use something other than mysqli!  Imagine
your company switching to another database server.  You'd have to
rewrite code in hundreds of functions!  This is where a database
wrapper class could have saved a lot of headache.  As it is, the least
expensive way to migrate databases permitted by the original
programmer's choice would be to write an adapter class and substitute
it in place of mysqli and hope there are no SQL incompatibilities.
Not very efficient though.

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php