[GRASS5] Database linking question

[Eric G . Miller]

On Wed, Jan 03, 2001 at 07:47:36PM +0000, David D Gray wrote:
> I feel that Berkeley DB is the best candidate for the embedded `native'
> attribute database. I have looked at the documentation, and it seems to
> fit the bill. It has basic relational capabilities and a good design of
> API, including Tcl interface. This also would be a plugin (and then gdbm
> would be redundant). I seem to recall that there were some license
> worries when Sleepycat took over the development and released versions
> 2/3, but the OSI hails this as a shining example of open-source
> development, so it is presumably OSD-compliant. On the face of it, it
> seems like a typical BSD-type license. Nevertheless that would have to
> be checked out.

Well.  Debian uses it by default, so the license must be DFSG compliant.
And they are very paranoid about licensing issues.

> I've just read up on the fruits of last night's discussion (my night
> here in Europe). The possibility exists of using postgresql as one kind
> of `interchange format'. I agree with Rich that there is no problem in
> principal in emulating an arc-node format with postgresql types. For
> example, a vector map called `vmap' could be represented by a set of
> tables like:

I wouldn't recommend using PostgreSQL's native geometric types for any
kind of active GIS data.  They just don't have the flexibility necessary
and there is a basic assumption of a cartesian coordinate space.
There's also the 8kb tuple limit which isn't fixed in 7.0, though there
is work on it.

> My understanding is that as of version 7.0.x, postgresql supports
> 
> 1) foreign keys, allowing efficient joins of the kind described above.

I don't know that the foreign key system is any more optimized than any
other kind of indexed key (I suspect not).  Though it's good to see
its inclusion.  PostgreSQL does very well, and outperforms MySQL under
certain circumstances (reportedly scales more linearly as the number of
users increase, and is better optimized for some join operations).  It's
not quite an ORACLE, but price/performance is probably more than
adequate for all but the most demanding applications.

 
> 2) a native R-tree implementation for querying geometric types.

Yes, they've had this forever I think.  The hard part is figuring out
how to get them to be used for indices (the docs are fairly weak or
wrong here).  If you index a "box" type, I think R-tree lookups are used
by default.  The "path" and "polygon" types have bounding box info
stored internally, but I can't say for sure if it is used in any kind of
lookups (it is used for queries of the "lines intersect?" variety).

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