According to Mark Imbriaco:
> > >>>>> "Perrin" == Perrin Harkins <[EMAIL PROTECTED]> writes:
> > Perrin> I think every RDBMS I've seen, includig MySQL, guarantees
> > Perrin> atomicity at this level.
> >
> > Look, Mummy, the funny man said MySQL and RDBMS in the same sentence :)
>
> Please don't start on this. I'm really sick of hearing Phil Greenspun
> harp on the evils of MySQL, and I don't think this is the place to relive
> that discussion all over again. Yes, I see the smiley, but this topic is
> so inflammatory that I felt a response in an attempt to prematurely stop
> the insanity was in order. :-) All databases suck. Pick the one that
> sucks the least for what you're trying to accomplish and move on.
Right, we don't need flames with no content, but there is always
the problem of knowing what is going to suck the least in any
new situation. For example I have one mysql database that typically
fields 200 concurrent connections, 10 million queries daily (mostly
concentrated in a 4 hour period) and is probably faster than anything
else that could be done on that hardware. However I recently inherited
another system that is falling on its face at a much lighter load. It
appears to be using tmp files to sort some ORDER BY clauses that
I haven't had time to fix yet. Is there any efficient way to pull
the newest N items from a large/growing table as you do a join
with another table? As a quick fix I've gone to a static snapshot
of some popular lists so I can control how often they are rebuilt.
Les Mikesell
[EMAIL PROTECTED]
