I was quite disappointed in this person's consideration of the problem of SQL and relational databases.<p>The following extracts from the discussion highlight some interesting misunderstandings:<p>> The mathematical foundation of SQL is relational algebra, which is an algebraic system used to perform batch structured data calculations. This is also why databases that use SQL are also called relational databases.<p>Unfortunately, SQL is not based on relational algebra. The reality is that it is based on a very distorted view of relational algebra as in it is based on tables, which are not relations but bags of records. It allows nulls to represents all sorts of information and the nulls are not treated in any uniform way.<p>> Relational algebra has been invented for fifty years, and the application requirements and hardware environment fifty years ago are vastly different from today.<p>The hardware requirements are an implementation function not a relational algebra function. As for application requirements, relational algebra is as applicable today as it has been at any time in the past. Relational algebra is problem space solution when the solution to the problem is the use of relational algebra. No one technique is universal as a problem space solution.<p>> Due to the large number of existing users and the lack of mature new technologies, SQL based on relational algebra remains the most important database development language today.<p>SQL has never been a mature technology. It is a commonly used technology, but highly flawed. There have been very few relational algebra implementations over the many decades. One that was developed was Dataphor's D4, but it didn't gain traction nor did it stay purely in the relational algebra domain, it was partly contaminated by the requirement of some SQL compatibility.<p>Many many years ago, one person did present an example of using D4 to build a solution to any interesting problem that was extremely difficult to solve using SQL. The D4 solution was elegant and very understandable. It was a beautiful example of solving a very difficult problem. The solution, if I recall correctly, involved using transitive closures to get the required results.<p>> Although there have been some improvements in the past few decades, the foundation has not changed. Faced with contemporary complex requirements and hardware environments, relational databases are not as adept.<p>There are no extent relational database technologies today, though there are quite a few SQL database technologies today. Most, of not all, so-called relational DBMS are lacking in the fundamental relational algebra requirements. Hence, they are unable to do what is part and parcel of relational algebra.<p>Though I disagree with various parts of the "The Third Manifesto", this tome does describe quite clearly what relational algebra is and what it is not. There is a third edition published as a pdf from [<a href="https://www.dcs.warwick.ac.uk/~hugh/TTM/DTATRM.pdf" rel="nofollow">https://www.dcs.warwick.ac.uk/~hugh/TTM/DTATRM.pdf</a>]. The material is not for light reading and you must be prepared to put on your thinking cap because it does get theoretical in many places.<p>As I said, I don't agree with some of their (Date and Darwen) views or requirements. But that doesn't at all detract from what they are saying.<p>> Relational algebra is too simple and lacks sufficient data types and operations. Therefore, when using SQL to describe the solution of a problem, it is necessary to find convoluted ways to implement.<p>SQL, as implemented in all the major SQL DBMS's, is too simple and lacks sufficient data types and operations. This says nothing about what is available within relational algebra. As pointed out above, a proper relational algebra language such as D4 does allow much easier solutions than the ABOMINATION database language SQL.<p>On the whole the discussion made by the author was lacking in so many ways.