Hi all,
here an interesting forward from sqlgrasslist... We discuss the future
DBMS for GRASS 5.1 there.
Markus
Well,
I can confirm that PostgreSQL has referential integrity (Release 7.0).
For what I hear, 7.1 will support outer joins, bigger tuples and should
be faster than the previous release. Moreover, it can support spatial
data
and has R-tree indexing built in... Postgres is an excellent choice if
you
have a GIS that handles both spatial and tabular data, and in particular
if they are related to each other (Ref. int.), but maybe it would make
a bit complicated to import/export data, since databases are composed of
several files placed in a standard directory (I may be wrong, but I
think
that all database should reside in /var/lib/pgsql/data, or another
folder
decided at install time). An export file should be composed of geometry
and
a dump of the table it references. At import time, table name could
conflict
with already existent tables... well, these are not big problems, but
it's
necessary to be aware of them. On the other side, an approach wich uses
only
file may be slow for what concerns thematic queryes (if attributes are
kept
in a file, how are they indexed for fast retrivial?)
Just opinions...
Bye
Andrea Aime
Markus Neteler wrote:
Hi all,
here an interesting forward from sqlgrasslist... We discuss the future
DBMS for GRASS 5.1 there.Markus
------------------------------------------------------------------------
Subject: Re: [SQLGRASS] Searching for GRASS 5.1 built-in DBMS
Date: Tue, 06 Mar 2001 20:42:56 +1100
From: John Reid <jgreid@uow.edu.au>
Reply-To: sqlgrass@geog.uni-hannover.de
Organization: School of Geosciences
To: sqlgrass@geog.uni-hannover.de
References: <200007191556.SAA00202@cc999683-a.wlgrv1.pa.home.com> <20010305192953.D15018@hgeo02.geog.uni-hannover.de> <002101c0a5b5$3cc7bb00$9075c180@godzilla>Hi,
"Jeff D. Hamann" wrote:
> Markus:
>
> What about MySQL? It's GPL and very stable. I'm not sure about other
> opensource projects, but it's even got odbc and jdbc drivers. Runs great
> under windows and the files are binary compatible between linux/win32.
>
> Jeff.>From a recent question I asked on the postgresql list (regarding databases
suitable for GIS):
<snip>
A definite No for 2 of the above. MySQL was built to be
fast and light, with a minimal feature set.
<snip>Further, probably the biggest problem with mySQL is that as far as I am aware
there is no support for referential integrity. I am fairly sure this is now
implemented in pgsql 7.1. I need to go back and play with it to make sure.Currently I am getting involved in the fmaps project. I think Franck has been
persuaded to go modular, so I am currently investigating what it will take to
implement a feature/metadata catalogue using the ISO draft standards for the
design schema. I was hoping that this module could also be used in the grass
and ossim projectsConclusion that I have come to so far is that an ORDBMS would make life much
simpler - possible to use ODMG support in python (http://4suite.org/index.epy
- has pg and oracle drivers) instead? Currently much of the object relational
support in pgsql seems to be broken (apart from user defined base type
extensions), and I don't know that C.J. Date would have approved of the method
used for implementing abstract data type attributes in a tuple anyway (oid
reference to separate table where all instances of ADT are stored)Then
again, I have just skimmed the surface so far, so hopefully I am very wrong
cheers,
John
----------------------------------------------------------------------
john reid e-mail john_reid@uow.edu.au
technical officer room G02, building 41
school of geosciences phone +61 02 4221 3963
university of wollongong fax +61 02 4221 4250uproot your questions from their ground and the dangling roots will be
seen. more questions!
-mentat zensufiapply standard disclaimers as desired...
--------------------------------------------------------------------------------------------------------------
If you want to unsubscribe from SQLGRASS
mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe sqlgrass'
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Tue, 6 Mar 2001, Andrea Aime wrote:
Postgres is an excellent choice if you have a GIS that handles both
spatial and tabular data, and in particular if they are related to each
other (Ref. int.), but maybe it would make a bit complicated to
import/export data, since databases are composed of several files placed
in a standard directory (I may be wrong, but I think that all database
should reside in /var/lib/pgsql/data, or another folder decided at install
time).
I do believe that all GISs have spatial and related attribute data. That's
implicit in a GIS. Regardless, supposedly environment variables to alternate
database locations (e.g., $PGDATA2) would work in 7.0. It was broken in 6.x
(took me a long time to learn that!) but on the list of changes for the new
version. I've not yet tested this. But, that removes the problem of having
attribute data far away from spatial data.
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
Making environmentally-responsible mining happen. (SM)
--------------------------------
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'