>>> I'm just in my 10th month of using CBB, and it starts to slow down a
>>> bit. Transfers are really getting slow (and I use them fairly often).
>>>
>>> I already have a mySQL database server running on my Linux box, and I
>>> would really like to have CBB use that.
>>
>> Yet another point in favor of DBMS'. The scalability of DBMS' far
>> outstrips that of flat files. For me, I have Quicken QIF3 files that
>> date back to 1982. I would like to have those files imported into CBB
>> so I can do some serious trending and data mining.
>
> Extracting data out of CBB (or GnuCash) into a DBMS is a perfectly good
> idea.
Hummm . . . that's an idea. Perhaps a set of utilities that can be
developed by third parties that are interested. These can be merged with
the current distribution.
> Trend analysis and data mining tend to be done using completely
> separate databases. They don't use online data; they use data extracts
> *from* the transactional systems.
The way I've usually seen it is that reports and analysis projects are
done at night "between 8:00 p.m. and 8:00 a.m." so as to maximize the CPU
and disk utilization of the server. You know . . . getting the bang-for-
the-buck of of the machine.
> People that try to do "data mining" in the R/3 system I help administer
> get their processes *killed off* when we notice it... The priority
> is for *payroll to run,* not for people to do after-the-fact analysis.
> Those that do can buy separate DB servers, and we'll be happy enough to
> extract data for them. (In the case of our payroll system, the folks
> doing "after-the-fact" stuff are the pension group...)
I guess that's one way to do operations. If I did that to a client, my
company would get sued.
> The guys using SAS to do nonlinear regression to find out that putting
> diapers and beer on adjacent displays is a Good Move don't need to
> have up-to-the-second data, and the people that are trying to do data
> entry certainly don't want the database locked up due to some idiot in
> marketing having a DB query that went bad, generating some huge temp
> table that blew out the DB server.
Oh, I hear ya there and your right. That's why night Ops handles these
types of queries. As you probably already know, if the data entry people
complain, the guys doing the reports get booted off until after hours.
> By having *separate databases,* everybody is left happy.
Hummm . . . what happens if your client doesn't want to spend the money on
that kind of solution? See what I mean? For us, there is a "time" for
everything.
Maxim: maximum utilization of all available resources.
> Data mining is an argument in favor of having a *separate* SQL
> database. It doesn't favor integrating an RDBMS *into* CBB.
Perhaps I will mention this to someone and see if they salute it or shoot
it as it goes up the flag poll. ;-)
Paul
---------------------------------------------------------------------------
Paul B. Brown [EMAIL PROTECTED]
President
Brown Technologies Network, Inc. http://www.btechnet.com/
Unix Systems Administration "Sailing is a state of mind . . . ."
---------------------------------------------------------------------------
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
