XML size (was: no subject)
07 Apr 2002 11:00:46 -0500
On Sun, 2002-04-07 at 10:02, Derek Atkins wrote:
> Andreas Bogk <email@example.com> writes:
> > Derek Atkins <warlord@MIT.EDU> writes:
> > > Unfortunately SQLite is not platform-independent (as per their FAQ),
> > > and Postgres, AFAICT, does not have an embedded server. I'm trying t=
> > > determine if MySQL has portable database files.
> > MySQL does not pass the ACID test, I'd recommend against using it for
> > financial purposes.
> To what "ACID" test do you refer?
> > Andreas
It's a standard test for RDBMSes. Here's a basic breakdown of what it
Atomicity - each transaction is treated as an all-or-nothing action
Consistency - data must always be logically correct
Isolation - each transaction is separate from other transactions
Durability - modifications to the database will remain persistent after
a system failure
It's a common test for the quality of a given RDBMS. MySQL says " MySQL
Server supports transactions with the InnoDB and BDB Transactional table
handlers. See section 7 MySQL Table Types. InnoDB provides ACID
http://www.mysql.com/doc/A/N/ANSI_diff_Transactions.html. I personally
am a little skeptical of MySQL. They continue to assert that
referential integrity is a function for the programmer and not for the
RDBMS. The only reason MySQL incorporated it is because they feared
losing market share to qualified RDBMSes.
On the Postgres site, (http://www.ca.postgresql.org/features.html)
there's this little tidbit:
Transactions allow all data modifications to be encapsulated in atomic
blocks. This allows the database to rollback and restore all original
data if there is an error in the transaction or if the database server
crashes. Transactions are a critical feature for ensuring data integrity
in database-backed applications.
* ACID compliant
* Support for rollback
* Serializable transaction isolation
* Works transparently with transaction features of interface
programs, such as Perl's DBI, Zope, JDBC and ODBC transactions,=20
The ACID test is very important when selecting an RDBMS. Postgresql had
the ACID compliance built in from the get-go. MySQL threw it on as an
afterthought when criticized by experienced and knowledgeable database
experts. Which would you rather use, built-in or afterthought?
That being said, and my loyalties being plain, many will nonetheless
want to use MySQL. Well and good for them--I believe the beauty of the
current and next generation of gnucash is that it allows you to add
plug-ins for back-end processing. While you should (IMHO) keep
Postgresql as the official SQL back-end, it would certainly be a benefit
to encourage development of other back-end engines, especially if the
GNUCash back-end interface is well-designed and documented (that last
one's alway a kicker, right? ;) ).
perl -e 'print
For 93 million miles, there is nothing between the sun and my shadow
I'm always getting in the way of something...
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----