Re: [phpgrabcomics-announce] PostgreSQL backend support

[Jim W. <jw...@ma...>]

> Hi Jim,
> I don't see a reason not to have a PostgreSQL backend.
>=20
> I didn't write the code because it has not been asked before by anyone.=

> Most of the users of phpGrabComics have access only to a fairly simple
> server configuration - and that was my case as well until December.
> PostgreSQL is often not available in cheap web hosting environments.

True, but it's available on my box in my apartment, and I'm doing my
best to keep MySQL off of it.  So far, so good  :)

> Some comments:
> -at the present time there is no database abstraction. I know it's bad,=

> but it was done for performance reasones.

I did notice.  Grep and I are good friends; it won't be too hard to add
an abstraction layer.

Is performance really that much of an issue with this software?  It
doesn't look that resource-intensive.  Personally, it looks like the
time delay in grabbing files from the original domains where they're
hosted would eat the most time / cycles / bandwidth.

With some good abstraction and a good database object, there shouldn't
be any delay outside of one more nested function... which I can't fathom
is that big of a deal (or what you mean when you say that it was done
for performance reasons).

> -at the present time you would have either to introduce a database
> abstraction level or to simply rewrite the database parts.
> -rewriting the database parts does not seem a good idea. It would imply=

> having to maintain too much code.

I agree completely; I was thinking abstraction all the way.  You mention
that you're making your code PHP5 compatible, is it kosher if I use
PHP5-only functions, or should I stay away from them?

> I have no objections in considering to restructure the code in
> phpGrabComics to use database abstraction, but only if the decrease in
> performance is not unreasonable.

If the decrease in performance is unreasonable, then I did an awful job
writing the abstraction layer, and you shouldn't integrate my code  :)

> I think that something below 20% might still be acceptable.

You were seeing 20% decreases in performance with an abstraction layer?!
 Something is very wrong with that figure.  I'm guessing that somewhere,
something very dumb was happening, like creating / executing / closing a
database connection for every query.  That's the only thing that makes
that figure make sense.

I promise you won't see that kind of performance hit  :)

> As database
> abstraction layer, MDB2 looks like a good candidate
> (http://pear.php.net/package/MDB2), as phpGrabComics is already using P=
EAR.

I know *of* PEAR, though I haven't ever used it.  I'll grab the code and
take a look.  I do respect your wish to use PEAR for parts of the
project; I'll see what I can do.

> If you are interested to do some work on it, and if the performance
> decrease will not be too bad, it would be interesting to include the
> code in phpGrabComics.

Sounds like we're coming from the same page on this one.  Thanks for the
reply.
--=20
Jim Wyllie
Master's Student
IRG Lab, Dept. of EE and CS
Ohio University