Re: Re: design of forum applications

On May 15, 2003 11:25 am, you wrote: > On Thu, 15 May 2003 10:18:05 -0400 > > "Ilia A." <ilia@prohost.org> wrote: > > Hi Hans, > > > > The problem with using PEAR in forum applications is scalability, > > which is why all major forum applications roll their own database > > abstraction layers. Unlike simple apps like blogs, forums tend to be > > complex high traffic applications where the overhead of PEAR is just > > impractical. > > The overhead of an abstraction layer when you need performances. PEAR is > not that small and I'm not sure we can say "the overhead of PEAR" :-). PEAR is much more then an abstraction layer for a database, it is an entire frame work. You cannot just take a single class from PEAR and use it as is, you'll need other parts of PEAR as well. So, let's say we are going to use MDB for our database needs. Now, our code includes a number of files that not only do the database abstraction but also PEAR style error handling, which is something we may not be using for the rest of out app. PEAR packages (this is not a bad thing per say) include a wide range of support for various databases, if our intended goal is to support MySQL, PostgreSQL and Sqlite, then support for oci8, fbsql, etc... is once again overhead. I'd say that PEAR is a good starting point to help you layout a frame work of your application. Perhaps, even power you app for a few early releases that will help you quickly get the 'boring' parts of the your apps engine and concentrate on more important things. However, once you've finalized the core of your own code and performance becomes an issue PEAR classes, in most cases, are something you'd want to replace with some custom code. I should point out this is not PEAR problem per say, any major general purpose class abstraction system will suffer from this regardless of the language. However, from the few packages I was genuinely interested in PEAR most were not written with performance in mind. Ilia