It's been rumoured that Rob Browning said:
>
> Pat Spinler <[EMAIL PROTECTED]> writes:
>
> > > This is something I've wondered, not being a big database person
> > > myself. Is there some technical reason why no one has ever
> > > implemented a free "database in a directory" system?
> >
> > A couple of reasons -
> >
> > *) most file systems don't handle the "lots of very small files in a
> > directory" very well.
This is indeed a traditional reason, although reiserfs for linux promises
to fix that. Historically VSAM on the mainframes was just that, and SQL
was invented some, what, 30 years ago? to overcome some of the
limitations that this thing had.
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.
> > -) fast key lookup
> > -) relational model (vrs hierarchical for a filesystem)
> > -) complex data joins
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. Using SQL as the wire
protocol for this would be a mistake for security reasons, compatibility
reasons, portability reasons. But if we don't use SQL as the wire
protocol, what do we use? XML? IIOP-RMI (corba==java rmi)? roll-your-own?
Any of these require you to define either an API or a data model of some
sort.
This is why it seemed wise to define a clear separation between
gui and engine. The separation allows gui end engine development to
prioceed separately, and allows you to not tangle up code from disparate
subsystems. To say that the 'gnucash engine data model is poor' is a
misleading statement: the limitation is on the part of the GUI, which
does not know how to handle anything more sophisticated than what the
engine provides. I'm confident that adding engine function and expanding
its data model is a far simpler task than coming up with the GUI to deal
with that.
> (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. I'm afraid
of stating this too strongly, because I think it'll raise hackles, but I
think there's real merit to modularity, objects, componenets, reusable
pieces. It would be a major mistake, a step back to merge sql and
scheme/gui together directly without abstraction in between.
--linas
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]