Re: [binarycloud-dev] Re: [PEAR-DEV] Re: [binarycloud-dev] Re: [PEAR-DEV] Re: [metabase-dev] RE: [PEAR-DEV] New Metabase Aniversary release

> > a) Don't really need to port it to another database that often > > b) Don't want to port it by using an abstraction layer, you'll want > > to design and optimize your tables differently on Oracle then you > > will on MySQL. > > ok I'll go back to my cave and code all my applications in C++ and compile > them into apache modules. hey, they would be fast when I was done :) > It would probably be more robust/well-designed/cleaner too, but that's off-topic... ;) Besides you use templating anyway, so why are you using PHP? You want a strong pre-defined set of classes, database abstraction, templating, etc. Why not just use C++, are you trying to make a political statement? :)) Anyhow, there is a huge difference, optimizing a database is about a million times more important than choosing a fast scripting language. Optimizing a database gives you speed, expandability, abstraction, etc. Its a big mistake to sacrifice database design at to the benefit of scripting engine abstraction. > actually, both of the things you said are for me untrue. > > I use the same schemas in oracle and mysql because metabase's XML schema > capabilities allow me to. That's a good thing. > EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH > Also, I certainly do have the need to be database independent because my > clients do make different technology decisions. I may well be porting an > application from oracle to DB2 shortly, and because of metabase I will have > very, very little trouble doing that. as of binarycloud r2 that process will > be even less trouble. > Yeah, but how much trouble would it be anyway (I mean really), replace a few Oracle query function calls with odbc function calls. The only thing that changes is the database schema, and a properly designed scheme can't really be abstracted anyway... > > DB abstraction and SQL abstraction do have there uses, no doubt (for > > example, applications that you give to other people), but they are > > certainly not "core components to any application." > > How many PHP application packages _don't_ use a database? I can tell you: > less than 5%. That's 99% of PHP's user base: people building applications > that talk to databases. > > If all those applications used a common abstraction layer, the PHP community > would benefit a great deal, as users could deploy applications on MySQL, > Oracle, DB2, whatever. > I highly doubt that. I've developed quite a few PHP applications, never needed to use a db abstraction layer. Database Abstraction is one of those features that everyone likes to implement as an excuse to not develop real applications. > >> Remember, PEAR ist not Midgard. PEAR is no application framework. > >> It's a pool of classes that follow coding standards. > >> > > Its more than that, its a unified/organized set of classes that > > follow coding standards. > > Define "unified" "organized" > Only if you define "sexual relations" :) However, dictionary.com does it nicely:: http://www.dictionary.com/cgi-bin/dict.pl?term=unified http://www.dictionary.com/cgi-bin/dict.pl?term=organized > Classes in folders with names that make sense? Or classes that have > underlying system design? > > > I do agree. I'm not saying "down with metabase", i doubt that > > manuel will be folding phpclasses.upperdesign.com anytime soon, and > > saying "PEAR is soooo great, ohhh my fucking god!" > > he he. Indeed no. > > > I think we should leave PEAR::DB as the only database backend, with > > a unified API (perhaps extended now with the inclusion of metabase). > > And then let users go to phpclasses if they want metabase, its not > > like its really that hard. > > the entire point is to get this all cleaned up in the community. 90% of > people agree on these points: > > -metabase is mature > -metabase is the most feature-rich > -PEAR's API is cleaner > > given that does it not make sense to take the good from each and create > something that is in the end, better? > > If sounds like you're happy to have people coding to the native database > functions in PHP for their applications? In the opensource world, that > doesn't work. > I'm agreeing with you.... (As far as your solution). I just had to pipe in when you and bjorn suggest that "database abstraction layers" and "templating engines" were crucial parts of any application. -Sterling