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

> Anyhow, there is a huge difference, optimizing a database is about a > million times more important than choosing a fast scripting > language. Ah, we disagree. The database is not the bottleneck for most applications. The real problems of well designed, maintainable code are not solved in the database. And certainly optimizations are not prevented by using XML schema abstraction. > Optimizing a database gives you speed, expandability, > abstraction, etc. I see the first two but not this last one: abstraction? > Its a big mistake to sacrifice database design at > to the benefit of scripting engine abstraction. I have not encountered any design feature of any database that I could not use with schema abstraction. > 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... Metabase does not abstract the schema, it abstracts its definition so DMBS specific SQL can be used to create the schema. And we're not talking about a few calls. Or are you suggesting I code my own abstraction layer for each application? >> 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. If you have common functions for establishing connections in one place, doing queries, etc... that's an abstraction layer. if you didn't use an abstraction layer you would have database calls _all over_ your code, if that's how you do it I don't ever want to maintain one of your applications. > 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 I was asking for a mechanical description; the result of "unified" code: shared error handling is one thing, system design is another. As for sexual relations, that's a perfect example: if you just said "I had sexual relations with (x)" and I knew you well, I (might if I was a bit drunk) say "what do you mean". So, what do you mean? My point was to make the distinction: >> Classes in folders with names that make sense? Or classes that have >> underlying system design? >> 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. Ok, point taken. I was making a generalization that I think most would consider reasonable. Anyway I think we both get the point. I didn't intend this to turn into a super-thread... _alex