[GRASS5] Database linking question

[David D Gray]

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...

"Eric G . Miller" wrote:
> 
> On Tue, Jan 02, 2001 at 12:36:26PM +0000, David D Gray wrote:
> > Hi all
> >
> > I would like to link some library/module routines to either gdbm
> > (preferred) or Berkeley DB. Can anyone comment if there are any problems
> > with that? eg. would it cause problems on some platforms?
> 
> I think gdbm is generally not maintained and Berkeley DB is often used
> instead (Sleepycat's software).
> 
> However, some considerations...
> 
> 1) It's my understanding that Berkeley DB and gdbm write data in a
> native platform specific mode (e.g. the files aren't portable).
> 

This would be used for the purpose of gaining access (but not too raw!)
to a data storage structure like a BTree or hash table - RDBMS like
postgresql or the native grass dbmi are really something different. I've
looked at ANSI C implementations of raw data structures, and I don't
fancy hacking, wrapping etc, anyway they are all incomplete. They are
only for temp operations (storing keyed represenations of bounding boxes
for example), not persistent data, so byte order issues don't matter.

> 2) Not much in the way of a type system.
> 

Yes and no. There is no type system as in a true RDBMS, but because you
have low level access to the data through a null pointer, you can store
anything. It's a sort of primitive `BLOB':

The kind of data that needs to be stored and processed is for example:

data:
struct {
	int seg;  /* Segment number of data element */
	int offs; /* Offset index of data element   */
}

key:
typically a string containing condensed geospatial co-ordinates.

The sort of processes would be  export/import, build, cleaning, binary
map operations, and so on.

> 3) Random access of large files isn't real efficient (though certainly
> better than GRASS's ASCII files).
> 

It's really only for sequential access, but gdbm uses a hash table and
DB can use either a hash table or a Btree (or flat files), which is
better for key lookup than ASCII files, and also better than the binary
tree structure included with GRASS.

> 4) No built in methods for things like joins.
> 

I think recent versions of DB do, but it as an API rather than
user-level process.

> 5) Different versions of Berkeley DB are binary incompatible.
> 

Yes. Minor versions at that...

> Admittedly, I have little experience with these files...
> 
> I've been looking around for some other options, but what I've found
> that looks good is always coded in C++.  A bit of a challenge to tie
> into GRASS's C code.
> 
> --
> Eric G. Miller <egm2 at jps.net>
> 


Regards

David

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