[EMAIL PROTECTED] wrote:
>
> I'll agree with cbbrowne in his statements that SQL more or less requires
> a DBA. As an old technology invented in the pre-unix, pre-windows world,
> it has a different idea about data management than what we're used to.
Maybe. I'd say it depends on the data store complexity and application
use of the data store. I can envision schemas that are "create and
forget" even in complex commercial dbs like sybase or oracle.
In particular, the existing gnucash data model is kinda neat that way,
since data is almost always added to accounts and rarely deleted, and
there's several good options for (non-incrementing) keys. In my
experience, requirements for regular dbs table maintainance generally
stem from one of these two issues (tables with dynamic content or with
keys that strictly increment as new data is inserted).
> Those are SQL pluses. SQL minuses are that you can't/wouldn't want to
> run it over the open internet, not even with SSL in place, say the
> way that CVS is internet-sort-of-safe.
>
> In particular, I occasionally daydream of gnucash as being a
> gui-front-end to some remotely located server. ...
On the other tenticle, there really _are_ no protocols that are
currently "internet safe". To start with, define "internet safe". :-/
Then, just to throw out a few issues you mentioned: Security ? Doesn't
yet exist except as a layered on encryption hack. Performance ? Who
can garruntee response time on the net, or even if it works ?
Portability ? You're going to end up with a custom solution no matter
what you do, so why worry ?
Until something usable in the way of infrastructure comes along, don't
sweat it. In particular, don't let undefinably vague future concerns
overly limit current implementation.
Really, all you can do is what you state here:
> This is why it seemed wise to define a clear separation between
> gui and engine. ...
Yup. Well defined API's are a _good_ thing. And you've done a nice
job, too.
> > (set! foo (somedb:create-database "/home/rlb/personal-accounts.gnc"))
> > (somedb:create-table foo ...)
> > (somedb:create-table foo ...)
> > (somedb:close-database foo)
>
> I do not mean to discourage an SQL back end; I think this would be great.
> But I think it would be a fundamental mistake to allow either the GUI
> or the scheme to manipulate the SQL directly as shown above.
Totally agree with you here. There's a strong arguement to be made that
data storage schema should never be dynamic.
Looked at from a DBA point of view - if you're creating a table for
anything other than a purely temporary usage (e.g. doing a set join)
there's something wrong with your application.
-- Pat
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
