Log in

No account? Create an account
Lord Yupa

February 2010

Powered by LiveJournal.com
Danger Mouse


Available documentation for PHP's "PEAR" project blows serious chunks.

They're sitting on what appears to be a reasonably decent database independent class (analogous to Perl's DBI class), and it's a royal pain to use because I can't find crap for information on it. Do they realize that developers (read, ME) want to use this, and would like to use this, assuming they could figure out how?

In other news, my porting of WikkiTikkiTavi, a really neat wiki to make use of PostgreSQL is stalling. The database abstraction layer designed into 'Tavi is not quite up to handling PostgreSQL (designed for MySQL), and the work it would take to get it directly working with Postgres is about the same as it would require to port it over to using the PEAR DB class.

Yeah, so now I just need to get the motivation to do that. Oh, and the knowledge.


PHP's lack of a database abstraction layer is one of the big reasons I started to dislike it - having a totally different API for ''every'' database really got on my nerves.
I agree. Although, I think it's even worse that they have one, which has been included since PHP 4.0 (in some form or another), but that they haven't documented, so no one knows about it.
I'd say DoTheSimplestThingThatCouldPossiblyWork - just port it to PostreSQL. If necessary, RefactorMercilessly so that all the database code gets isolated in one little module. But why write with pear if you don't need to? YouArentGonnaNeedIt.
Well, as things stand right now, WikkiTikkiTavi has a single module where all the database code is abstracted to. The problem is that the abstraction layer was written by someone who only knew MySQL, so it doesn't take into account that other databases might want a different type of information to execute certain functions.

So, as things stand right now, I'm going to have to go through and change every single place that calls a function from the database abstraction class in Tavi, just to port it to Postgres. Additionally, if I do a straight port to Postgres, then I end up forking the project, and I'll be forced to maintain my own branch on it.

Being the lazy programmer that I am, I have little desire to maintain my own branch on this. If porting it to PEAR's DB class requires only a little more work than porting it to Postgres directly, and means that someone else will maintain it once the code is merged, then I'm willing to do that.
Now you've got those concepts in mind, ask yourself: Why do I need a relational database? OurPlace (850 pages) uses in-memory objects and serialization, and won't need rewriting to use more efficient storage for quite a while. According to WardsWiki, the average page size is about 1k, which means 1Meg of RAM per 1024 pages. Big whoopie. :) (meanwhile since everything's in memory, searches and retrievals are incredibly fast).
Bleh. ;-)

I'm familiar with your opinions with regards to relational DBMS's, and to a point, I even agree with you. But I do think they are appropriate for certain situations.

Specifically, when all or most of these occur:
  • You're already making use of a relational DBMS for other things, so it's installed, setup, and running, already.

  • You're working with a program that someone else wrote, that was designed as a relational Database front end.

  • When dealing with Perl and/or PHP, 'cause they're just so slick with a relational DBMS.

  • When one of the features that is on the "to do" list is allowing for the upload of binary information, specifically, pictures.
To be perfeclty honest, though, the main reason I'm using a relational database is because, for this project, it's less work to continue using one than to use something else. ;-)