XML size (was: no subject)

Matthew Vanecek mevanecek@yahoo.com
07 Apr 2002 11:00:46 -0500


--=-4sFW1pJKn8xWuMPAqmvG
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun, 2002-04-07 at 10:02, Derek Atkins wrote:
> Andreas Bogk <andreas@andreas.org> writes:
>=20
> > Derek Atkins <warlord@MIT.EDU> writes:
> >=20
> > > Unfortunately SQLite is not platform-independent (as per their FAQ),
> > > and Postgres, AFAICT, does not have an embedded server.  I'm trying t=
o
> > > determine if MySQL has portable database files.
> >=20
> > MySQL does not pass the ACID test, I'd recommend against using it for
> > financial purposes.
>=20
> To what "ACID" test do you refer?
>=20
> > Andreas
>=20
> -derek

It's a standard test for RDBMSes.  Here's a basic breakdown of what it
means:
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
compliancy." at
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
      etc.


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? ;) ).

--=20
Matthew Vanecek
perl -e 'print
$i=3Dpack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
***************************************************************************=
*****
For 93 million miles, there is nothing between the sun and my shadow
except me.
I'm always getting in the way of something...

--=-4sFW1pJKn8xWuMPAqmvG
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

iD8DBQA8sG0uOMmiB1jXEBsRAt2dAJ42GOQ2hVVQFO4OEQXa5JykyLLFOACdHBY1
zm2jHT40vljeoyltwCm/k58=
=RSJk
-----END PGP SIGNATURE-----

--=-4sFW1pJKn8xWuMPAqmvG--