[GRASS-user] Database advice

Dear list,
I go back and forth between GRASS and QGIS for a recent assignment. I'm considering dumping all my GRASS vector attributes to the same table created by SpatiaLite (my default vector back-end for QGIS) so that I can query attributes easily, irrespective of GIS. My questions are:

1. Will there be serious performance penalties for doing this?
2. Is there a way to specify a single database, regardless of mapset,
    in GRASS or do I need to do this separately for each mapset?

I am presently keeping the databases separate and attaching them as schemas for queries, which I figure is the "conventional" way of doing things. However if I do so, I need to stick to front-ends which support schemas.
Thanks in advance for your suggestions.
Regards,
Ravi

--
R.S. Bhalla

On Sat, Nov 24, 2012 at 4:52 PM, R.S. Bhalla <rsbhalla@gmail.com> wrote:

Dear list,
I go back and forth between GRASS and QGIS for a recent assignment. I'm
considering dumping all my GRASS vector attributes to the same table created
by SpatiaLite (my default vector back-end for QGIS) so that I can query
attributes easily, irrespective of GIS. My questions are:

1. Will there be serious performance penalties for doing this?

Do you mean to have one SQLite DB? There may be some locking issue
on Windows but perhaps it does not apply here.

2. Is there a way to specify a single database, regardless of mapset,
   in GRASS or do I need to do this separately for each mapset?

Commonly there is one SQLite DB per mapset.
With db.connect the settings could be changed. But note that you can only
write in the current mapset (I suppose that also applies to the DB backend).
The best would be of course to try out and report.

I am presently keeping the databases separate and attaching them as schemas
for queries, which I figure is the "conventional" way of doing things.

It depends: SQlite is a file based, no overhead DB and not a server. If
stored in a SQL based server this may fully apply.

However if I do so, I need to stick to front-ends which support schemas.
Thanks in advance for your suggestions.

Maybe other list members have more experience here than me.

Best
Markus

Thanks for your inputs Markus,

Yes, as you predicted, there are some locking issues in Q-GIS if the same table is accessed, but not otherwise (I use linux).

Also specifying a single database was simple enough in db.connect <db.connect driver=sqlite database=$GISDBASE/$LOCATION_NAME/db.sqlite>. However table names have to be unique. This is obvious and I should have tried this earlier, sorry.

Regards,
Ravi

On 12/03/2012 06:13 PM, Markus Neteler wrote:

On Sat, Nov 24, 2012 at 4:52 PM, R.S. Bhalla <rsbhalla@gmail.com> wrote:

Dear list,
I go back and forth between GRASS and QGIS for a recent assignment. I'm
considering dumping all my GRASS vector attributes to the same table created
by SpatiaLite (my default vector back-end for QGIS) so that I can query
attributes easily, irrespective of GIS. My questions are:

1. Will there be serious performance penalties for doing this?

Do you mean to have one SQLite DB? There may be some locking issue
on Windows but perhaps it does not apply here.

2. Is there a way to specify a single database, regardless of mapset,
    in GRASS or do I need to do this separately for each mapset?

Commonly there is one SQLite DB per mapset.
With db.connect the settings could be changed. But note that you can only
write in the current mapset (I suppose that also applies to the DB backend).
The best would be of course to try out and report.

I am presently keeping the databases separate and attaching them as schemas
for queries, which I figure is the "conventional" way of doing things.

It depends: SQlite is a file based, no overhead DB and not a server. If
stored in a SQL based server this may fully apply.

However if I do so, I need to stick to front-ends which support schemas.
Thanks in advance for your suggestions.

Maybe other list members have more experience here than me.

Best
Markus

--
R.S. Bhalla, Ph.D.
/Sr.Research Fellow/
Foundation for Ecological Research,
Advocacy and Learning (FERAL)
No.27, 2nd Cross,
Appavou Nagar, Vazhakulam
Pondicherry 605 012
Ph. +91 413 2225441, 2671566
Fax. +91 413 2671567
Web: http://www.feralindia.org

On Mon, 3 Dec 2012, R.S. Bhalla wrote:

However table names have to be unique. This is obvious and I should have
tried this earlier, sorry.

Ravi,

   That's true for all SQL databases. It infrequently bites me by accident
with my postgres vector attribute tables when I make changes to the tables
in GRASS.

Regards,

Rich