---------- Forwarded message ---------- From: Fergus Gibson <fgibson75@xxxxxxxxx> Date: Fri, Nov 28, 2008 at 12:47 AM Subject: Re: Fwd: Fwd: MySQLi connections To: "J. Hill" <jh@xxxxxxxxxxx> On Wed, Nov 26, 2008 at 9:38 PM, J. Hill <jh@xxxxxxxxxxx> wrote: > I understand there are many cases where database abstraction layers are > preferable, but in some applications which are heavily dependent on a > specific database's unique functions, it seems to me that avoiding > abstraction would decrease the complexity and improve the performance of the > application -- at the cost of making it more difficult to switch database > servers. I don't necessarily mean something pre-built. You can create your own abstraction by writing a class composed of the database object you want to use. As long as you have a consistent interface and use encapsulation, you get all the benefits of abstraction. It actually hides complexity at the same time that it makes it easier if you need to migrate to a different database server in the future. The key to abstraction is to hide everything but the interface from the rest of the application so that the other elements can't become dependent on the specific implementation. [...] > instead just put > all the core mysqli calls into a library -- cleaner than scattering them > across all the files. That's pretty much the same thing. ;) The point is that only one component of your application should have to know about the database. The rest of it should be completely ignorant. That way, you only have to update that one component in a migration. What sort of object or functions you use to do the actual database operations is not my point. It's about ensuring that the rest of your application never knows if you're using MySQL, SQL Server, Oracle, Postgres, or something else. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
