[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