Unterschiede bei der SQL-Implementierung für den Datentyp 'ST_Geometry'

Die Implementierung von Spatial SQL (ST_Geometry) für Informix, DB2, Oracle, PostgreSQL und SQLite unterscheidet sich nur geringfügig. Esri (und IBM, was Informix und DB2 betrifft) hat versucht sicherzustellen, dass die Normen des Open Geospatial Consortium (OGC) so weit wie möglich berücksichtigt wurden.

Dabei sind allerdings zwei Ausnahmen zu beachten, die jedoch keinen Verstoß gegen die Normen des OGC, sondern lediglich geringfügige Implementierungsunterschiede in Bezug auf das Datenbankmanagementsystem darstellen.

• Prädikatwerte

  Die Eigenschaftenfunktionen von "ST_Geometry" in Informix und PostgreSQL geben ein "t" für TRUE und ein "f" für FALSE zurück, wohingegen "ST_Geometry" in DB2, Oracle und SQLite "1" für TRUE und "0" für FALSE verwendet.

  In diesem Beispiel für Informix SQL gibt die SELECT-Anweisung nur die Gebäude-IDs zurück, für die die Funktion "ST_Contains" ein "t" für die Grundstücke zurückgibt, die Gebäudegrundrisse enthalten.

  select bf.building_id "Building id"
  from buildingfootprints bf, lots
  where st_contains(lot,footprint) = 't';
  

  Für Oracle gibt die SELECT-Anweisung dieselben Gebäude-IDs zurück, für die eine ähnliche Funktion "ST_Contains" den Wert "1" für Parzellen mit einem Gebäudegrundriss zurückgibt.

  select bf.building_id "Building id"
  from buildingfootprints bf, lots
  where sde.st_contains(lot,footprint) = 1;
  

• Angeben von Funktionen

  Beim Ausführen von SQL bei Tabellen in Enterprise-Geodatabases in Oracle müssen die ST_Geometry-Funktionen mit dem Schemanamen qualifiziert werden.

  Beim Ausführen von SQL bei Tabellen mit ST_Geometry-Spalten in DB2, Informix und PostgreSQL können die ST_Geometry-Funktionen qualifiziert werden. Dies ist jedoch nicht erforderlich.

  Da SQLite keine Schemanamen verwendet, werden die ST_Geometry-Funktionen beim Ausführen von SQL für Tabellen mit ST_Geometry-Spalten nicht qualifiziert.