Re: [GENERAL] PostgreSQL, GnuCash
On Aug 1, 2004, at 6:26 PM, Christopher Browne wrote: Measuring it as binary installs: - Installing PostgreSQL on Debian requires adding a 9.8MB package. - Installing MySQL on Debian requires adding several packages adding up to (+ 8.7 0.2 1.0 0.6), or roughly 10.3MB. - Installing FireBird2 requires (+ 2.2 0.7 2.4 1.8) or about 7.1MB. I compiled PostgreSQL on Mac OS X with optimization -Os (for size) and the resulting installation was less than 2 MB. I am looking to embed it in applications to reduce administrative effort, so size matters in my case. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[GENERAL] PostgreSQL, GnuCash
Would PostgreSQL be a good enough choise for GnuCash (or Quickbooks or the likes) type of program? What could be the potential drawbacks of using PostgreSQL (perhaps its big size)? What would be a better database for that kind of job? Kaarel ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] PostgreSQL, GnuCash
Kaarel wrote: Would PostgreSQL be a good enough choise for GnuCash (or Quickbooks or the likes) type of program? I believe GnuCash runs on PostgreSQL, so yes. What could be the potential drawbacks of using PostgreSQL (perhaps its big size)? I don't think so. What would be a better database for that kind of job? None. :-) -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] PostgreSQL, GnuCash
Quoth [EMAIL PROTECTED] (Kaarel):
Would PostgreSQL be a good enough choise for GnuCash (or Quickbooks
or the likes) type of program? What could be the potential
drawbacks of using PostgreSQL (perhaps its big size)? What would be
a better database for that kind of job?
The main plausible drawbacks to using PostgreSQL are that:
a) It introduces some system administration burdens, if you're
not careful.
b) It runs as a separate server process, which has some performance
costs in comparison with embedded database systems like
Berkeley-DB or SQLite.
If PostgreSQL seems to be somehow too expensive, then you have
essentially two choices: Berkeley-DB and SQLite.
MySQL is _not_ smaller, and does _not_ introduce any less in the way
of sysadmin burdens, so it doesn't provide meaningfully better
answers for those issues.
What PostgreSQL buys you that none of the other three database
systems mentioned is the capability to have the database strongly
enforce Way Lots of aspects of data integrity. Comparing...
- If you try to store an invalid date, PostgreSQL will reject it.
- In contrast, the other 3 DBs do no meaningful validation of
input.
For a financial application, you want a fixed-point decimal numeric
type so that you can be confident that it is calculating values
correctly.
- PostgreSQL provides NUMERIC(SIZE,DECIMALS) that deals with this
nicely, and which never imposes floating point round-off errors on
you.
- Berkeley-DB has no way to express data types; data is merely
a payload, so you'll implement whatever type you choose,
and if you're working in C or C++, that probably won't be a
BCD-like numeric type.
- SQLite does not impose any data type constraints, and stores
non-integer values as floating point values, which will not
calculate correct values for financial transactions.
sqlite create table accounts (name text, balance numeric(10,2));
sqlite insert into accounts values ('chris', 27.50);
sqlite insert into accounts values ('dave', '28.751');
sqlite insert into accounts values ('brad', '29');
sqlite insert into accounts values ('doug', '29.9');
sqlite select * from accounts;
chris|27.50
dave|28.751
brad|29
doug|29.9
sqlite select sum(balance) from accounts;
115.25099
- MySQL does appear to have a numeric type that can store
rows correctly, but it then breaks if you ask it to do aggregates,
as it collects them into a floating point variable. Oops.
I'm quite prepared to trust PostgreSQL with financial numbers; none of
the other options are at all acceptable for that purpose.
--
select 'cbbrowne' || '@' || 'cbbrowne.com';
http://www.ntlug.org/~cbbrowne/postgresql.html
If you spend more on coffee than on IT security, then you will be
hacked. -- Richard Clarke
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [GENERAL] PostgreSQL, GnuCash
Oops! [EMAIL PROTECTED] (Kaarel) was seen spray-painting on a wall: What could be the potential drawbacks of using PostgreSQL (perhaps its big size)? Big size seems an unlikely thing to actually be true. Contrary to popular misconceptions, MySQL is certainly _not_ smaller than PostgreSQL. The source tarball for the production release of the former is 13.2MB in size, whereas PostgreSQL 7.4.3 weighs in, lately, at 12.1MB. Measuring it as binary installs: - Installing PostgreSQL on Debian requires adding a 9.8MB package. - Installing MySQL on Debian requires adding several packages adding up to (+ 8.7 0.2 1.0 0.6), or roughly 10.3MB. - Installing FireBird2 requires (+ 2.2 0.7 2.4 1.8) or about 7.1MB. (This according to my firewall box that has no databases running on it...) Seeing as how there's quite a bit more functionality in PostgreSQL, you've got to wonder why MySQL is so bloated... -- If this was helpful, http://svcs.affero.net/rm.php?r=cbbrowne rate me http://www.ntlug.org/~cbbrowne/spreadsheets.html Everyone likes flattery, and when you come to Royalty, you should lay it on with a thick trowel. -- Benjamin Disraeli on Queen Victoria ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
