Différences de mises en œuvre SQL du type ST_Geometry

Il existe peu de différences entre les implémentations du type SQL spatial (ST_Geometry) pour Informix, DB2, Oracle, PostgreSQL et SQLite. Esri (et IBM, dans le cas d'Informix et de DB2) ont collaboré pour garantir la meilleure application possible des normes établies par l'OGC (Open Geospatial Consortium).

Il existe toutefois deux exceptions qui n'enfreignent pas les normes de l'OGC mais qui sont des différences d'implémentation d'ordre mineur propres aux systèmes de gestion de bases de données.

• Valeurs de prédicat

  Les prédicats de ST_Geometry dans Informix et PostgreSQL retournent un t pour TRUE et un f pour FALSE, alors que ST_Geometry dans DB2, Oracle et SQLite utilisent 1 pour TRUE et 0 pour FALSE.

  Dans cet exemple de code SQL Informix, l'instruction select retourne uniquement les identifiants de bâtiments pour lesquels la fonction ST_Contains retourne t, correspondant aux lots de construction comprenant des emprises d'immeubles.

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

  Pour une instruction SELECT pour Oracle, cette même fonction ST_Contains retourne les mêmes identifiants de bâtiments pour lesquels un 1 est retourné lorsqu'un lot comprend une emprise.

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

• Qualification des fonctions

  Les fonctions ST_Geometry doivent être qualifiées avec le nom de la structure lors de l'exécution du SQL sur des tables dans les géodatabase d'entreprise dans Oracle.

  Vous pouvez qualifier les fonctions ST_Geometry lorsque vous exécutez SQL sur des tables dotées de colonnes ST_Geometry dans DB2, Informix et PostgreSQL, mais ce n'est pas obligatoire.

  SQLite n'utilisant pas les noms de structure, vous ne pouvez pas qualifier les fonctions ST_Geometry lorsque vous exécutez SQL sur des tables dotées de colonnes ST_Geometry.