[GRASS5] Re: question about sqlite

[Michael Barton]

OK. I understand better what you are suggesting. As long as something like
v.in.db could still work with external dbf files, grass could simply link to
an external dbf file, and grass could output dbf files, this should work
fine. It would indeed be nice to have a richer set of SQL commands the
default in GRASS--and the possibility for a better attribute management
interface.

Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Wed, 19 Oct 2005 20:13:19 +0100
> To: <daniel.calvelo at minag.gob.pe>
> Cc: Michael Barton <michael.barton at asu.edu>, Radim Blazek
> <radim.blazek at gmail.com>, grassdev <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] Re: question about sqlite
> 
> 
> Michael Barton wrote:
> 
>> DBF is a widely used, standard format--in spite of being old and klunky. It
>> can be imported or read by a wide variety of other programs (e.g., Open
>> Office, Excel, Access, Filemaker). It is also the standard table format for
>> ESRI, MapInfo, and Idrisi. It would be very inconvenient to drop it.
> 
> I wasn't suggesting dropping support for DBF as an *external* data
> format, but for the DBF driver. IMHO, external DBF files should
> imported with e.g. v.in.dbf, not manually inserted into the GRASS
> database.
> 
> Daniel Calvelo Aros wrote:
> 
>> What I think Glynn had in mind is not accessing DBF files through a
>> GRASS DBMI driver but rather convert them to SQLite (and back,
>> eventually) and not bother anymore about parsers, SQL and the lot.
> 
> That's exactly what I had in mind.
> 
>> I'd say yes, let's build converters between DBF and sqlite3 files (and also
>> between txt/csv formats and sqlite3) and drop sqlp, since the equivalent in
>> SQLite is much better and powerful. As an aside, deprecate DBF and propose
>> sqlite3 as the default storage format, starting from (say) 6.2.
>> 
>> That would mean having GRASS depend on sqlite, of course.
> 
> Well, it would depend upon having at least one database backend,
> whether that's SQLite, PostgreSQL, MySQL or ODBC.
> 
> AFAICT, the only advantage to the DBF driver is that we bundle it with
> GRASS. SQLite does essentially the same thing (i.e. both are
> server-less, zero-configuration DBMSs) but does a better job of it.
> 
> If it's essential to bundle at least one database backend, we could
> always bundle SQLite (the code is public domain).
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>