On Tue, 09 Nov 1999 17:47:06 CST, the world broke into rejoicing as
Pat Spinler <[EMAIL PROTECTED]> said:
> Christopher Browne wrote:
> >
> > On Tue, 09 Nov 1999 14:54:55 PST, the world broke into rejoicing as
> > "jools enticknap" <[EMAIL PROTECTED]> said:
> > >
> > > Perhaps. I'm not saying that the Java version should be SQL only.
> > >
> > > I'm just saying that it makes writting reports easier, and a little more
> > > flexible.
> >
> >(snip)
> >
> > Once you jump to an SQL model, you can certainly create more sophisticated
> > reports, but this comes at the cost of the increased complexity of having
> > to "do SQL."
>
> Depends - I haven't looked at the core code, but if the data
> store/retrieval functionality is reasonably well modularized, it
> shouldn't be too hard.
>
> > > In once sence I do agree, trying to get a DBA to allow access to
> > > databases it a little like getting blood from a stone.
> >
> > Sometimes DBA's appear to be trained to be jerks;
>
> Hey. *I'm* a DBA. Careful there. :-)
I could say things about "pointy-haired bosses," as well as about security
administrators too, and probably get other people riled up. :-)
The point there was that when people that don't understand databases ask
for things, and don't know that:
-> That extra index may come at substantial cost
-> That thing you want to modify is part of the *PRIMARY KEY,* and is
thus NOT MODIFYABLE.
-> Granting you access to that table means that you have access to stuff
that company policy doesn't want you to have, and providing access to
*part* of the table may slow performance down for everyone...
Disagreements pop up largely out of ignorance on the part of those that
don't understand what's going on.
The situation is worsened when there isn't anyone to be a DBA; the DBMSes
that are available on Linux are largely not all that "management free."
> > the *real* point is
> > that by going to something like MySQL or PostgreSQL, *someone* has to
> > be assigned the task of "being the DBA," as a DB instance needs to be set
> > up for use by the financial software.
> >
> > The point is that it's not as simple as:
> >
> > # rpm -i mysql-1.1.i386.rpm
> > or
> > # apt-get mysql
> >
> > And "then it all works." It *doesn't* all work; you need to do some
> > DBA work to allow apps to access it.
>
> True - but it doesn't have to be this way. I'm a bit surprised that
> no-one has made postinstall scripts for the various db packages to
> create some default database(s).
>
> For the purposes of getting GnuCash to use a db store, I'd be willing to
> make a script to create a small database for gnucash in, say, postgresql
> if anyone wanted it. Then this could just be included with the
> distribution as part of our install process.
It gets scary real quick:
a) My install isn't in the precise location that your script expects.
Presumably a good script can search for where it should find PostgreSQL;
this is not the big problem.
b) But I want to customize this a bit and connect to PostgreSQL on another
box.
This makes life quite bad immediately, as there's more config involved,
and the bad part is that if the default installation "protocol" is
strongly oriented towards "local PostgreSQL," it may prove quite a
pain to recustomize for "my configuration."
--
"...and scantily clad females, of course. Who cares if it's below
zero outside" -- Linus Torvalds
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
