It's been rumoured that Christopher Browne said:
> There are two approaches:
>
> a) Change over wholesale to MySQL or PostgreSQL, with all the resultant
> horrid administrative results, bloat, and licensing questions.
> Not particularly attractive.
> b) Create some sort of "middleware" level in between GnuCash and the
> "data store," thus providing the option of using your choice of:
> [ Text File | Something-like-DBM | SQL DBMS ].
OK guys, let's back up and look at this objectively.
1) What is our target audience?
On one extreme, we have "Oma" who can hardly install gnucash.
On the other, we have "Mega-Corp" with its entire accounting section,
payroll division, e-commerce, etc.
I can assure you that the "correct" backend database is NOT the same for
both of these. We can either limit our audience or be poly-datastore.
2) Assuming that we wish to include "SQL DBMS" as a possible datastore,
a) Are we going to take advantage of its full power? If so, most reports are
really just a DB query and a little "boiler plate"; reconciliation is an
interactive select followed by an update. This is certainly a different
structure from that which we currently employ.
b) Are we going to limit ourselves to a particular DB? Doing so may limit
our audience because different organizations may have chosen a different DBMS
for other reasons.
I'm sure that there are good reasons to select and/or reject each of a whole
range of possible approaches. However, I think that it is important that we
first set down the real goals so that each solution can be objectively
evaluated with respect to those goals. Having a DBMS that meets the "ACID"
test probably doesn't give "Oma" any real value. OTOH, it might be the only
way to meet the requirements of "Mega-Corp". But that should be a conclusion
rather than a requirement. We must think in terms of "value to the customer".
In the end, we might conclude that the "single flat file" is the best
solution. After all, there is a company that is quite successful using that
approach. ;-)
But I don't really think so ...
