On Mar 5, 2009, at 5:44 PM, <grass-dev-requ...@lists.osgeo.org> wrote:
Date: Thu, 5 Mar 2009 19:04:46 +0100
From: Markus Neteler <nete...@osgeo.org>
Subject: Re: sqlite and grass65: was Re: [GRASS-dev] sqlite and
grass64
To: Moritz Lennert <mlenn...@club.worldonline.be>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Message-ID:
<86782b610903051004n5601199ax269f60f1949c6...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Mar 5, 2009 at 4:38 PM, Moritz Lennert
<mlenn...@club.worldonline.be> wrote:
On 05/03/09 10:43, Markus Neteler wrote:
..
Suggestion:
make SQLite as default DBMS driver in devel_branch6 (alias GRASS
6.5).
Since today, in 2009, the driver has received a lot of testing, is
definitely superiour to DBF (where we regularly get complaints).
+1
If allowing one file per map isn't too hard to implement as optional
feature it might be a (last) requirement to make it the default
driver.
I think that for the same arguments as those brought forward by
Glynn above,
we should make single file db the default. Anyone who really needs
it can
easily create a per-vector db with v.db.connect.
Remember that Glynn mentioned that joins won't work in this case.
Concerning the need to be able to easily backup/share, I think we
definitely
need some module which isolates and exports a series of chosen maps
in a new
temporary mapset with a local sqlite db file, copies the chosen
maps into
this temp mapset and then creates a tarball (or zip or whatever)
with the
basic LOCATION info (i.e. a PERMANENT mapset with PROJ and WIND
files) and
the temp mapset. Shouldn't be too hard to wip up, or ?
Essentially a v.pack/v.unpack, right?
Markus
I like the idea of sqlite. But I also favor 1 db per vector.
Portability is important. Think about the issues with ArcGIS (a real
pain).
Joins between different vectors indeed won't work if there is one db
per vector. But how many times does one want to join the attribute
table of one vector with the attribute table of a different vector?
I'm sure that there could be cases, but I'd warrant that there aren't
many. More often one wants to join multiple tables for the SAME
vector. In this case, you would have multiple tables for a single
vector db.
Michael
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
