[GRASS5] Database linking question

[Eric G . Miller]

On Tue, Jan 02, 2001 at 06:16:04PM +0000, David D Gray wrote:
> Hi Eric
> 
> Thanks for your remarks. My question was perhaps over-brief, because
> what I'm looking for is something different from the usual questions
> about RDBMS's...

Okay, I thought this was in reference to a native "embedded" attribute
system (long term storage...).  Anyway, some of the things I've been
following would appear to have the kind of flexibility you're looking
for; however, there's the C++ -> C bridge which is harder than the
reverse.

Of interest...

Coldstore  (An object/mmap storage system; C++; Alpha; limited to
platforms with ELF objects; Probably never practical for use in GRASS).

MetaKit ("efficient embedded database library"; C++/Python/Tcl; Stable;
portable, flexible, reportedly handles "moderate-sized" databases ("few
Megabytes") very well and does well with larger databases when
programming works with it's "columnwise data model"; Has testimonials! ;
platform agnostic; promising except for that C++ issue).

xBase (well known format(s); C++ library; limited data types and ranges;
16bit charsets not supported???; requires "cleaning" to remove dead
data; possible but C++ issue again);


I've started investigating the "educational" RDBMS Leap just to see one
implementation of a relational database that tries to stay close to the
Relational Algebra and C. J. Date's view's on RDBMS's.  Not really
useful in itself for an embedded database system, but worthy of study.

Anyway, I'll keep hammering away at this, but for GRASS to be a
contender in the Vector GIS arena it really needs a robust, data
attribute system (Relational is nice, SQL is unnecessary and probably
undesirable).  I really don't want to try to reinvent the wheel either
(I'm not sure I'm up to it anyway) so I'd prefer to find an existing
solution that can be "plugged" in.  I'm not sure what you all have in
mind for the future GRASS Vector library, but I think it needs to take
into account this need and should try to make it simple for the module
programmer to handle (perhaps transparent in some instances).

Ciao,

-- 
Eric G. Miller <egm2 at jps.net>

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'