Re: Common DB Abstraction Layer: Re: [PEAR-DEV] Adoption of Metabase

Hello, Pierre-Alain Joye! > > I don't exactly agree. > > Of course most web developments with php use mySQL (or similar BD) so the > > porting is a very light issue > > Of course, enterprise development (intranet, portals..) use other BD.. but the > > porting is still a very light issue except if you company change very often its > > licensing policy switching vendors back and forth ;- ) > > So may be for your specific enterprise IT environment PEAR::BD right now > > doesn't fit your needs.. fine.. some day hope this will change, but its more > > a "do you support DB XX ?" issue than a "are you cross DB ?" one. > If you develop a complete application (a KMS by example), you will like to create a standart > version that you don't have to customize. Customer A uses Oracle, B uses Sybase and C uses > SQLserver, the best way for the connectivity part is real abstraction layer whatever you use for the > application itself. You don't have to create new queries, stored procs and so on, every times > you ve got a new rdmbs to work with. > For your internal application needs, effectivly you will not change BD every day, and as far > you respect SQL standarts, it's not a great jobs to move. May I put my 2 cents..?:) I mean, this discussion looks like discussuon about HTML-Standard(w3c) for MS Internet Explorer and Netscape Navigator, because the Web-Designers have the same problem in creation of sites. I even don't talk about JS for there two browsers..:) IMO problem consists in database-specific SQL dialect. We have SQL92(for example), _but_, also we have DB-specific features, _and_(worst of all), we have defferences of SQL-standard in concrete DBMS. I think, the problem is here, and what can do pear-developers with difference in SQL for DBMS? IMO, nothing, exept only ask DBMS-developers to follow the sQL92 standatd..:) It's really long discussion... -- Best regards, KVN. PHP4You (<http://php4you.kiev.ua/>) mailto:kvn@php.net