Manuel Lemos wrote: > > Hello André, > > On 03-Aug-01 10:31:30, you wrote: > > >But what other issues are there? Should there not be a part of the PHP > >documentation dedicated to describing all the things you should worry about > >if you want to write portable code? Shouldn't there be a "portability > >standard" for PHP, or is there allready one? I'm sure there must be other > >things to consider than the three features/settings I have mentioned, and > >getting a good overview/reference for these would be a boon to everyone > >trying to write portable code. > > >This also cover coding practices, like using relative paths and urls rather > >than static ones, maybe even using abstraction layers on top of the DB (if > >using one). > > A lot of people uses database abstraction layers, but many of the existing > database abstraction packages are not really concerned with application > portability but rather just using the same set of API functions: for > instance PEAR-DB almost just tries to be a look a like Perl DBI but none of > these really do much to help you to develop database independent > applications. > This is not necessarily a bad thing > Of all I know, only ADODB and Metabase really try to abstract data types so > you don't have to handle the different data type representation that vary > between databases. For instance, almost all SQL databases support date and > time types, but you can't assure that all of them use the same date format. > The packages above do that for you if not for all, at least for most data > types. ' > > Metabase even goes further. Besides the application runtime API, Metabase > provides a database independent way to install and maintain database > schemas: tables, fields, indexes and sequences. > > It lets you describe your schemas in a database independent XML format. Then > it creates the database structures for you without the need for the user to > do any SQL programming. Besides that, if you change you database schema > description, Metabase is able to alter your schema without disturbing any > data added to the database after you have installed. > I think you can over do abstraction - in my opinion if you are going to use a different database learn about that database properly and not rely on a php class to do the work for you, learn the datatypes, the differences in features (eg no LIMIT in Sybase, Interbase, Sapdb - and others), different ways indexing work etc etc, the list of differences is very long. Sure you can have an abstraction layer handle these differences but in some cases your performance will take a big hit. (there is no good php work around for LIMIT). Just because you can use an abstraction layer to everything doesn't mean you should. Reliance on it might give you portability but performance and good design will suffer I'd pick one of the lighter weight database classes that are only doing the basic stuff and stick to that. Rewriting queries for each database (if neccessary) and writing stored procuderes and triggers for them may take extra time - but at least I know I will get maximum performance from my database. > Anyway, at least regarding database application, there seems to be no > agreement to what portability features should be present in an abstraction > package or else we wouldn't many of such packages, unlike Java, Perl, > Python, etc.. > why is that such a bad thing ? I > It seems to be a waste of opportunities, but sometimes developers are more > concerned with pleasing their egos and do their own abstraction package > and be famous (or not) with it, rather than reaching to a consensus. > Maybe its because have developers have different needs from a class. Just because yours is right for you and probably many others doesn't mean it's "the class" to use. Im sure Metabase is very good but people should look around because there is no "one size fits all" class. > Regards, > Manuel Lemos -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
