Key word is might. Remember, premature optimization is the root of all evil.
On Tue, Oct 6, 2009 at 13:46, Huan Truong <[email protected]> wrote: > On Tue, Oct 06, 2009 at 12:31:48PM +0100, Alexander Horn wrote: >> It typically yields a suboptimal solution to tie yourself to a >> particular database vendor. Depending on your requirements it is often >> very helpful to introduce a data access abstraction layer that gives >> you additional freedom in reacting to scalability requirement changes >> or database system developments. > > Keep in mind that you don't get portability for free. Any DB abstraction > layer might create overheads and might decrease the power of the DBMS you're > going to use. > > Jeff Atwood has one interesting post on db abstraction: > > The problem is that we're attempting to spackle a nice, clean abstraction > over a database that is full of highly irregular and unusual real world > behaviors. > > http://www.codinghorror.com/blog/archives/001281.html > > - H. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkrLkJIACgkQELk86Tv8blRDzwCcDwOsKH87KN1vbtPhTB+NqA0C > 1ccAoIu42JX0AnfPvKi5FfQfS7cmHhWp > =aDFD > -----END PGP SIGNATURE----- > > ----------------------------------------------------------------- To get off this list, send email to [email protected] with Subject: unsubscribe -----------------------------------------------------------------
