|
I agree.
I've always thought SQL was a great example of set theory put into practice. You specify the elements (select items) and conditions (where clause) to return the (sub)sets you want.
Spatial data is also about sets - a polygon is theoretically defined as the set of points contained by a perimeter. A line is the set of points between specified points (complicated somewhat by coordinate systems). I have found the set based approach of SQL
& relational databases is a very comfortable fit with spatial data queries - Postgres + Postgis is an awesome combination, then add hstore, jsonb & timescale to the mix and I have no need for a NoSQL db for key/value rather than normalised data.
I also suggest that as a simple language to retrieve stored data, SQL works well. But as we try to do more complex retrievals, the difference between a query to ask for data and a query to ask for a somewhat complex analysis of the data becomes very apparent.
Yet these extensions, as is so often the case, are where the true power and the limitations of SQL can be found.
>From a pragmatic perspective, the useability & value to the global community of relational databases and SQL is self evident. They have been and continue to be incredibly successful and useful. Whether you like it or not, they work, and have solved many problems
for people and organisations for many years.
I have yet to see the complainers achieve what Codd & Date did, many years ago.
So from me, if no-one else, a heartfelt thank you to everyone who has contributed to the SQL/Postgres space which enables me to do so much!!
In appreciation,
Brent Wood
Principal Technician, Fisheries NIWA DDI: +64 (4) 3860529 From: Steve Litt <slitt@xxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, September 15, 2021 16:54 To: pgsql-general@xxxxxxxxxxxxxxxxxxxx <pgsql-general@xxxxxxxxxxxxxxxxxxxx> Subject: SQL queries as sets: was The tragedy of SQL Rich Shepard said on Tue, 14 Sep 2021 05:49:07 -0700 (PDT)
>On Mon, 13 Sep 2021, Guyren Howe wrote: > >> They are making a decent decision. SQL is a *fucking terrible* >> language, which I don’t blame them for not wanting to learn. > >>> SQL is not the problem. Problem are the devs. I love SQL. I hate >>> orms. The problem with databases is people refuse to treat it as >>> the entity it is and want to use their beautiful OO system. Problem >>> is databases are not OO. We need to recognize that and treat >>> databases as databases. > >Guyren/Hemil, > >As a non-SQL expert who's used postgres since 1997 I've come to >believe the basic issue is that SQL is based on sets, neither >procedural or object oriented. Few people think in sets so they try to >fit SQL into what they know rather than understand the how sets work. Rich, could you please elaborate on SQL queries being based on sets? I never thought of it that way, and would like to hear your related thoughts. SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist https://aus01.safelinks.protection.outlook.com/?url="">
|
