On Wed, 21 Nov 2001 16:14:04 +0100 (MET) Luc Saint-Elie <[EMAIL PROTECTED]> wrote:
> En réponse à Pierre-Alain Joye <[EMAIL PROTECTED]>: > > > > This definition defines more a common interface to connect to a db, > > execute queries, fetch the result and eventually gives errors reports > > ;). > > Somehow yes (do I still win the $15,000 ???) :) christmast time soon... ;) > 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. > The result is that the question (IMHO) is more a "is it possible to adapt > PEAR::DB to my specific case ?" (been at risk that the answer is "no") > than "how could we start from the beginning to build something else?" The wheel ? ;) pa -- 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]
