[GRASS5] Multiple attribute support in GRASS5.1:someconsiderations (long)

[Radim Blazek]

Frank Warmerdam wrote:
> Radim Blazek wrote:
> > SQLite seems to be a good solution. The only problem I see is that there
> > is no GUI front-end which was one of my criteria. Dbf files may be edited
> > in StarOffice and MSAccess (including forms). I thing that we don't have
> > human resources for developing database front-end within grass and we
> > don't want to reinvent wheel. So if such front-end is available is
> > important.
>
> Radim,
>
> It seems to me that if we use easily substitutable SQL based RDBMS systems
> then folks that need forms support and a GUI front end can choose an
> RDBMS that has them.  If we use DBF and depend on external gui front ends
> it still won't be possible to distribute GRASS database forms applications
> since different users might choose different target RDBMSes, right?

At this stage of grass development I think this is the only way, i.e.: 
grass (with minimal functionality for accessing attributes) + external GUI 
front-end for RDBMS. 

> Is the GUI front end and forms requirement just so that users can see their
> data interactively, or so that substantial forms based applications can be
> built?

Some simple forms for viewing data interactively must be part of grass
(such simple tcl/tk form for db sites editing is already db.attr accesible by 
db.what in g50) but for real applications we must use some third party
solution (library is not enough, visual designer is needed) I think.

> Someone mentioned the issue of having different programs for different
> databases.  I completely agree that if we integrate SQL support smoothly
> into GRASS that the applications should be insulated from the actual
> database backend by some sort of plugable library.  This might be based on
> an existing standard like ODBC or just a custom simplied database API.  I
> was impressed with the relative simplicity of the abstracted database
> interface in Python.
>
> BTW, does Postgres have a nice gui front end?  I have always done my work
> from psql, but I would dearly love to try something a little more visual.
> :-)
> > BTW: SQLLite files are not portable (The key size thus depends on the
> > size of an integer on the host computer.) but that doesn't matter.
>
> This is annoying.  In the short term I guess it would be necessary to do a
> database dump and reload to transport to different system types.  I would
> ideally like to see some sort of automatic translation be done at lower
> performance at some point.

Yes, but dump (vector export, import) will be needed anyway because of 
different user RDBMSes. 

Radim

> Best regards,
>




---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'