> I haven't seen the new mysql. My feeling is that all things being
> equal, gluing transactions on top of a database implementation can
> not possibly be as stable and correct as building them in from the
> beginning. The design heuristic that applies is "Make it run first,
> THEN make it run fast." Mysql was built to run fast from the
> beginning, and now they're jamming in functionality. So if I needed
> transactions I'd go with postgres until mysql has a track record.
You may be right, though they did this with berkeley db, which I guess is
pretty stable with transaction support.
The problems I'm having with postgresql are mainly in the area of blobs. I
need to store several binary objects, generally in the 800-2400 byte range,
and I also need to store text messages sent by people, and I have to deal
with truncation and such to stay within the 8k row-size limit. I've heard I
can update the blocksize to 32k, but then I've read this has other negative
impacts and that 7.1 solves it anyway -- but when will that be stable and
ready?
Anyway, I'm giving them both a quick test, primarily with regard to
transactions and blobs. I can report back what I learn, but it will only be
at a testing level, and I'd prefer to hear from production users.
David
