Update of "Virtual Tables (misc)"
Not logged in

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview

Artifact ID: 6301be65aadd141a627a41499f355e3f12e9d8fb
Page Name:Virtual Tables (misc)
Date: 2018-08-22 08:55:52
Original User: sandro
Parent: c14fe1d90e3238e66d8c5e1b1690a50c316e8d30 (diff)
Next b909a6392335b23bfdfa8458f2ea91059b4ced60
Content

back to main page

VirtualShape

The VirtualShape Interface allows to directly access an external ShapeFile by using standard Spatial SQL queries.
Syntax for creating a VirtualShape Table:
SELECT CREATE VIRTUAL TABLE my_table USING VirtualShape ( shp_path , charset_encoding , srid );

SELECT CREATE VIRTUAL TABLE my_table USING VirtualShape ( shp_path , charset_encoding , srid , text_dates );

SELECT CREATE VIRTUAL TABLE my_table USING VirtualShape ( shp_path , charset_encoding , srid , text_dates , colname_case );
Supported arguments and their interpretation:
Note: quoting or not any Text String when it appears as a Virtual Table argument has absolutely no effect.
SELECT CREATE VIRTUAL TABLE my_table USING VirtualShape( /home/sandro/myshp , CP1252 , 3003 , 1 , lower );
or
SELECT CREATE VIRTUAL TABLE my_table USING VirtualShape( '/home/sandro/myshp' , 'CP1252' , 3003 , 1 , 'lower' );
Both notations will produce exactly the same identical result.

Best practices and known limitations

  • Virtual Tables are not really genuine Database Tables, they are just pretending to be.
  • Virtual Tables have very poor speed performances when compared to genuine Database Tables.
  • Complex SQL queries JOINing several Tables can often return odd and misleading resultsets, if one or more of the JOINed Tables are of the Virtual type.
  • The best usage you can do of a Virtual Table is to just support basic data import processes, or to quickly get an overall glance at a full dataset without necessarily importing it into the Database.
  • Pretending to use a Virtual Table as a full replacement of importing all data within a genuine Database Table is strongly discouraged, and never is a smart idea.


VirtualDBF

The VirtualDBF Interface allows to directly access an external DBF table by using standard Spatial SQL queries.
Syntax for creating a VirtualDbf Table:
SELECT CREATE VIRTUAL TABLE my_table USING VirtualDbf ( dbf_path , charset_encoding );

SELECT CREATE VIRTUAL TABLE my_table USING VirtualDbf ( dbf_path , charset_encoding , text_dates );

SELECT CREATE VIRTUAL TABLE my_table USING VirtualDbf ( dbf_path , charset_encoding , text_dates , colname_case );
Supported arguments and their interpretation:
Note: quoting or not any Text String when it appears as a Virtual Table argument has absolutely no effect.
SELECT CREATE VIRTUAL TABLE my_table USING VirtualDbf( /home/sandro/myshp , CP1252 , 1 , lower );
or
SELECT CREATE VIRTUAL TABLE my_table USING VirtualDbf( '/home/sandro/myshp' , 'CP1252' , 1 , 'lower' );
Both notations will produce exactly the same identical result.

Best practices and known limitations

  • Virtual Tables are not really genuine Database Tables, they are just pretending to be.
  • Virtual Tables have very poor speed performances when compared to genuine Database Tables.
  • Complex SQL queries JOINing several Tables can often return odd and misleading resultsets, if one or more of the JOINed Tables are of the Virtual type.
  • The best usage you can do of a Virtual Table is to just support basic data import processes, or to quickly get an overall glance at a full dataset without necessarily importing it into the Database.
  • Pretending to use a Virtual Table as a full replacement of importing all data within a genuine Database Table is strongly discouraged, and never is a smart idea.


VirtualText

The VirtualText Interface allows to directly access an external Text file by using standard Spatial SQL queries.
The Text File is expected to contain a properly formatted Table accordingly to some Delimiter-Separated-Values format (comma separated values *.csv, tab separated values *.txt and alike).
Syntax for creating a VirtualText Table:
SELECT CREATE VIRTUAL TABLE my_table USING VirtualText ( textfile_path , charset_encoding );

SELECT CREATE VIRTUAL TABLE my_table USING VirtualText ( textfile_path , charset_encoding , first_row_as_titles );

SELECT CREATE VIRTUAL TABLE my_table USING VirtualText ( textfile_path , charset_encoding , first_row_as_titles , decimal_separator );

SELECT CREATE VIRTUAL TABLE my_table USING VirtualText ( textfile_path , charset_encoding , first_row_as_titles , decimal_separator , text_separator );

SELECT CREATE VIRTUAL TABLE my_table USING VirtualText ( textfile_path , charset_encoding , first_row_as_titles , decimal_separator , text_separator , field_separator );
Supported arguments and their interpretation:
Note: quoting or not any Text String when it appears as a Virtual Table argument has absolutely no effect.
SELECT CREATE VIRTUAL TABLE my_table USING VirtualText( /home/sandro/myfile.txt , CP1252 , 1 , POINT , NONE , TAB );
or
SELECT CREATE VIRTUAL TABLE my_table USING VirtualText( '/home/sandro/myfile.txt' , 'CP1252' , 1 , 'POINT' , 'NONE' , 'TAB' );
Both notations will produce exactly the same identical result.

Best practices and known limitations

  • Be aware: opening big or huge text files could easily require massive RAM allocations.
  • Warning: attempting to access an external Text file by blindly specifying random choosen delimiters and separators may easily have catastrophic effects.
    Always carefully check the actual payload of the Text file before attempting to access it.
  • Virtual Tables are not really genuine Database Tables, they are just pretending to be.
  • Virtual Tables have very poor speed performances when compared to genuine Database Tables.
  • Complex SQL queries JOINing several Tables can often return odd and misleading resultsets, if one or more of the JOINed Tables are of the Virtual type.
  • The best usage you can do of a Virtual Table is to just support basic data import processes, or to quickly get an overall glance at a full dataset without necessarily importing it into the Database.
  • Pretending to use a Virtual Table as a full replacement of importing all data within a genuine Database Table is strongly discouraged, and never is a smart idea.

back to main page