Revisiting the database
Fri, 29 Sep 2000 18:36:11 -0700
That was quick!! :O) OK, you caught me. I estimated, based on the fact that the
local grocery store now sells 500 MHz PCs for under $500 with rebate.
However the MySQL data is based on a single processor 350 MHz PII (three years
old). Folks who are used to watching Access grind away for hours can be surprised
by the performance of a real, tuned ISAM database.
I can't see anyone having an accounting system large enough for performance to be a
significant issue. On the contrary, I would be very surprised if a db-based
GNUCash weren't faster than the present system for large account sets. For small
ones, either approach would do but the maintenance and robustness points would
Thanks for your intellectual rigor as well as your position!! :O)
> > As for performance, nowadays a majority of users are running 400 MHz or
> Is this observation from personal experience or have you managed to query a
> majority of users? I haven't managed to query a majority, but of the users I do
> know, none has anywhere near this level by a factor of at least 2 and that
> lucky soul was just the latest to update his 8 year old computer. I think you
> are being verrrrrrrry optimistic about your assumptions of the financial
> resources of the majority of users and their willlingness to chase the latest
> and greatest from Intel.
> I do think think your observations about an external, commonly used DB are
> correct though.
> > better machines. A fast database could perform almost any query
> > imaginable for this application in one or two seconds, even for
> > accounting systems with thousands of records. Using MySQL I have run a
> > variety of queries including summing data from 100,000 rows of data that
> > still run fast enough to be almost invisible to the user. Some
> > databases slow down on complex joins, but that would be necessary only
> > on annual reports and similar problems.
> gnucash-devel mailing list
"We feel that this change will be sufficient to discourage "hackers",
although it is obviously insufficient to protect a node against a
determined and malicious attack."
- RFC521 (ftp://ftp.isi.edu/in-notes/rfc521.txt), 1973
Gary E Bickford, mailto:garyb-at-fxt.com.
Web and content/asset management systems, PHP, XML, Apache, SQL
FXT Corp, http://www.fxt.com, tel. 541-383-2749