Tim Perdue wrote:
> I'd really love to see a case where a real-world page view requires 4x
> the queries on MySQL. If you are doing subselects like that on a website
> in real-time you've got serious design problems and postgres would
> fold-up and quit under the load anyway.
Why? There are some subselect queries that have no problems running in
real-time. There are some non-subselect queries which one should never
attempt in real time. There is nothing fundamentally wrong with using
subselects for page views if it works for you. Nor is there anything
necessarily wrong with a design that requires subselects.
> > Do you run on a magic power grid that
> > never fails?
>
> Reality is that postgres is as likely - or more likely - to wind up with
> corrupted data than MySQL.
What do you base this statement on? With your sample size of one
corrupted postgres database? Also do you include inconsistent data in
your definition of corrupted data?
> Never in two years of programming PHP/postgres have I ever used
> commit/rollback, and I have written some extremely complex web apps
> (sourceforge being a prime example).
I would humbly suggest that you are doing it wrong then.
> Geocrawler.com runs on postgres and
> again, I NEVER saw any need for any kind of rollback at all.
So what do you do when you get an error and "get out" as you put it?
Leave the half-done work in the database?
> The statelessness of the web pretty much obviates the needs for
> locks/rollbacks as each process is extremely quick and runs from start
> to finish instantly. It's not like the old days where you pull data down
> into a local application, work on it, then upload it again.
Even in the "old days" you should never keep a transaction open while
you "work on it". Transactions should *always* be short, and the web
changes nothing.
Really, REALLY there is nothing different about the web to traditional
applications as far as the db is concerned.