"Suder Steen SFS" wrote If I can administer both DB's from within Zope, then I'll choose PGSQL becaus e you say they're equally easy to work with an PGSQL has transaction control. Can I administer DB's from within Zope?
PGSQL's advantage is transaction control and MySQL's would be tools and userbase, right?
Don't underestimate transactions - does the Zope Mysql interface do rollback if a page is partially rendered? Databases with transactions (particularly when they're supported by Zope :) make life _so_ much easier - you don't have to worry about what happens if one SQL Method fails, but there's been previous ones in the same DTML Method that might or might not have succeeded... Anthony
I would suggest considering Zope2/ZODB3 as the database for the application, and not using SQL at all. If I were building an issue tracking system from scratch today, I would probably start with Zope2 and no SQL, and I speak as someone who's written an SQL-based tracking system on ZPublisher that currently supports around 450 users answering about 40,000 requests a month. At 07:49 PM 8/31/99 +1000, Anthony Baxter wrote:
"Suder Steen SFS" wrote If I can administer both DB's from within Zope, then I'll choose PGSQL becaus e you say they're equally easy to work with an PGSQL has transaction control. Can I administer DB's from within Zope?
PGSQL's advantage is transaction control and MySQL's would be tools and userbase, right?
Don't underestimate transactions - does the Zope Mysql interface do rollback if a page is partially rendered? Databases with transactions (particularly when they're supported by Zope :) make life _so_ much easier - you don't have to worry about what happens if one SQL Method fails, but there's been previous ones in the same DTML Method that might or might not have succeeded...
participants (2)
-
Anthony Baxter -
Phillip J. Eby