[Gvsig_english] Definition query

andrea.peri at regione.toscana.it andrea.peri at regione.toscana.it
Thu Jan 31 08:37:11 CET 2008


> gvSIG use the "limitation SQL string" as is or parse it ?

Just to say that implementing a SQL Limitation on shapefile seem to be a little more complex
than on a DBMS Engine, because there isn't a "shapefile engine" with sql capabilities.

So if for a sql engine is sufficient to take the limitation-text and append it to sql query (with some adjustment of course).

For a shapefile is necessary to parse the text-limitation understand the clauses
AND, OR, NOT, LIKE, (, ) , nested and so on.

And after apply it procedurally .

And all this can be is more slowly.

Of course is a useful feature, and there is even on AV3.

But I think it is not so important just because the future (quite near) is on DBMS.

Even because on DBMS is possible to use the full power of a relation-DB.
For example on DB is possible to create a relation (foreign-key) between two geometry fields.

Insert a record only if the geometry of a record is equal to the geometry of another field.

This type of interaction is impossible with shapefiles.
Neither the geodatabase can do this (use the foreign-key)
it use a procedural-approach to the DB and not use all the relation-power of the DB.

Another think is the size:
the data-size is growing now all data go forward higher details: 1:2000 and more.
Shapefiles has a phisical limit to 2GB that is of-course again bit far, but a 500MB shapefiles is 
not good to work on a AV3 and the situation is not better on a gvSIG (for java-dependency).

ps: the choices do from ESRI with geodatabase technology make it more sensible to the growth of size of the archives.

So there is a choice for programs like gvSIG to have a usefulness.

So I think is better the think to specialize on the DBMS as good choice for a program like gvSIG.


Andrea Peri.




More information about the Gvsig_internacional mailing list