RE: [PHP] Database abstraction

Manual, A properly written ODBC driver _should_ hide most of those things from the application. The ODBC API provides support for querying the database about autoincrementing capability (SQLColAttribute's SQL_DESC_AUTO_UNIQUE_VALUE). There are hundreds of other calls that drivers will make to describe back end functionality, based on the return values of the driver you should be able to handle differences. Plus, an ODBC driver in many cases should mask functional differences, performing appropriate translations for different databases. Returning limited result sets should be handled by a cursor. There are five cursor models, that an ODBC driver should support: static, forward only scrollable, bi-directional scrollable, keyset driven, and mixed. Even static or forward only, which is what most databases and drivers support, are enough to handle basic result-set returns. Proper implementations abstract it even further, and give the application writer freedom from concern about differences in databases. The point here is that the driver should handle this mapping of functionality, so if a database doesn't support a bi-directional scrollable cursor, for instance, the driver should impose that functionality by mapping the appropriate SQL calls to the CLI of the database and performing any necessary work under-the-covers. Lastly, (since I'm ranting anyway :) ODBC should be faster than native drivers. The reason is that native drivers connect a client layer to the native communications protocol, which then speaks to the Call Level Interface of the database. So you have 2 layers on top of the CLI in a "native" connection. Proper ODBC should bypass the native comm layer entirely, so you have one comm layer supplied by the ODBC vendor that speaks directly to the CLI. Add in the impetus that 3-rd party vendors have to make their products provide the same functionality regardless of back end database, and you start to see ODBC moving into it's own as a proper format for achieving database agnostic applications. I hope this has been helpful - not tryign to argue per se, just dispel some myths about ODBC. Yes, all those slow/limiting/difficult myths were true several years ago, but because of the commodization of databases, a few vendors have worked to realize the promise of ODBC. Best regards, Andrew ---------------------------------------------------- Andrew Hill Professional Services Consultant OpenLink Software http://www.openlinksw.com Universal Database Connectivity Technology Providers > -----Original Message----- > From: Manuel Lemos [mailto:mlemos@acm.org] > Sent: Tuesday, August 29, 2000 8:53 PM > To: Andrew Hill > Cc: php-general@lists.php.net; yrojas@juno.com > Subject: RE: [PHP] Database abstraction > > > Hello Andrew, > > On 24-Aug-00 10:41:23, you wrote: > > >Or you could just use ODBC, as this is what it is intended for... :) > > I'm afraid ODBC does not do enough for complete database abstraction. > > Metabase goes farther. Not only it abstracts access, but it also > abstracts > the installation of databases. In this context, when I say databases, I > don't mean just the tables and fields, but also indexes and sequences. > > While trying to implement a Metabase driver to use ODBC, I got stuck > while trying to implement sequences support. The problem is that I can't > figure if the underlying database supports any sort of sequences system. > > Not all DBMS support sequences, but most of those that don't support them, > they support at least one auto-incremented field per table. Metabase > emulates sequences with such fields in separate tables for those > databases. > > My problem with ODBC is that not only I don't know how to figure what > support to sequences/auto-increment the database of a given ODBC data > source may provide. > > Another puzzling doubt is about how to retrieve a limited range of rows of > a result set, like you can use LIMIT clause in MySQL. Metabase provides a > way to achive this very easily in a database independent manner, just by > calling MetabaseSetSelectedRowRange before executing a query. > > I have no idea how to figure what support the underlying database has in > ODBC. I have to default to skiping any initial page rows and emulate a > result set that is limited to the specified row limit if smaller, but I'm > afraid this won't prevent the server from hogging the CPU fecthing large > result sets. > > If you have any idea about these ODBC puzzles, please let me > know. If not, > I usually discourage the use of ODBC under PHP despite there is > significant > demand. > > > > Regards, > Manuel Lemos > > Web Programming Components using PHP Classes. > Look at: http://phpclasses.UpperDesign.com/?user=mlemos@acm.org > -- > E-mail: mlemos@acm.org > URL: http://www.mlemos.e-na.net/ > PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp > -- > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, e-mail: php-general-unsubscribe@lists.php.net > For additional commands, e-mail: php-general-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net > >