Re: Sensible and NonsenSQL Aspects of the NoSQL Hoopla

The paper does not mention the spatial databasers. What are there historical part of the NoSQL movement?

For example http://www.spatial.maine.edu/~max/RJ6.html not only argues against actual shortcomings of SQL1 in the standard of 1898 http://www2.yk.psu.edu/~lxn/IST_210/sql1_versus_sql2.html but also against the relational model. However, I simply don't get some of the arguments therein:

• The tabular representation "is not the most natural form for modelling spatial data and leads to unnecessarily complex queries." [p. 2]

What does that mean? Is "most natural" equal to "representable in one single table"?

• High level spatial concepts can only be "simulated" in "terms of the few, predefied non-spatial concepts". [p. 2]

What is the difference beween "simulating" concepts on a computer and "not simulating" them. Does an algorithm only "simulate its functionality in terms of elementary operations"?

• The relationships of pure SQL, such as 'less' or 'greater', are too low level to address all the spatial concepts sufficiently. [p. 4]

This is simply a completely unsubstantiated claim. And wrong, too.

• "overloading of SQL's standard predicates [...] is insufficient for spatial relationships because the set of standard predicates in SQL is too small to cover all spatial relationships." [p. 5]

In contrast, all the "spatial relationships" (aka nine-intersections) can be modelled and queries with SQL1. However this is not an elementary task.

• "The description of graphical display of the query result has drawn only little attention." [p. 5] "Relations are only displayed in tabular form." [p. 9 "Decoupled retrieval and display"].

At that time IRIX was already available. It had the "dual" shortcoming of lacking DBMS functionality. OpenGL today is still lacking DBMS functionality ;).

• "no interaction with the currently displayed result is possible." [p. 6]

This shortcoming of SQL1 that has also been critisized by others and has been removed in 1992. These "others" did not merely toss away SQL.

• "[...] SQL [...] does not support such fundamental as metadata queries and higher order queries." [pp. 6-7] "As SQL lets users query only the values of the tuples, it does not support metadata queries." [p. 8]

This is called "catalog" and was also required by Codd himself (Codd RMV2 1990). This shows that the authors was not familiar with the relational model with which they confounded SQL. Implementation of missing catalog functionality by the data modeller does NOT introduce redundancies. Also, why are catalog queries more important for spatial data than for other application domains?

• "... the retrieval part of SQL is inherently value based, i.e. all operations are performed on attributes, and tuples can only be compared for equal values, but not for identity." [p. 7]

Codd: "We shall see, the unique identifier is the name of the R-table, together with its primary key value." (RMV2 1990) So the tuple name (primary key value) IS the tuple identity. Note that the author again showed non-familiarity with the relational model.

• "For example, although it is possible to ask for 'all roads in Penobscot county that are wider than the road from Bangor to Bar Harbor' it is impossible to formulate an SQL query for 'the relation between the widths of Interstate I95 and Route 1A', with an expected answer such as, 'I95 is wider than Route 1A'" [p. 8]

    "SELECT r1.name

     FROM r1 road, r2 road
     WHERE r2.name = "1A" and
           r1.width > 2.width" [p. 9]

First, the quoted query is syntactically wrong. It should read

  SELECT r1.name
  FROM road r1, road r2 -- tuple variables go after table names   WHERE r2.name = '1A' and -- string constants are 'single quoted'

         r1.width > 2.width;

The SQL1-queries

  CREATE TABLE OPS(op char not null primary key);

  INSERT INTO OPS(op)values('<'),('='),('>');

  SELECT r1.name as road1, OPS.op AS relation, r2.name as road2   FROM road r1, road r2, OPS
  WHERE r1.name='I95' AND r2.name = '1A' AND

         ((r1.width > r2.width AND OPS.op = '>')  OR
          (r1.width < r2.width AND OPS.op = '<')  OR
          (r1.width = r2.width AND OPS.op = '='));

show that "impossible" equals "impossible for the author". Maybe this query demonstrates why "SQL per se is already difficult to use." [p. 11]. It may be necessary to write non-elementary queries. Non-familiarity with SQL, too .

• "SQL per se is already difficult to use." [p. 11]

Yes. Correct syntax is hard to learn and non-elementary queries are difficult to write.

The problem is, that this old claim that bare SQL be unsuitable for spatial data still seems to be believed in. At least I have the impression that there still exist people who believe in such publications and that they put firm resistance against any attempt towards using the classical relational model for spatial data. This means that people which have such poor knowledge in the relational model that they produce or believe in such gibberish are still confounded with experts.

Norbert Paul

Jan Hidders wrote:

> One of the best and most insightful reads in the SQL vs noSQL debate
> I've seen lately:
>
> http://www.edbt.org/Proceedings/2013-Genova/papers/edbt/a2-mohan.pdf
>
> -- Jan Hidders
>