Does Sql Hinder Nimble Databases

There seemed to be more NimbleDatabase choices (or at least activity) back in the late 80's and early 90's than there is now. Some give blame to OOP popularity reducing interest in such tools, but some also suggest that the SQL language is the culprit because of its large and complex grammar. The earlier tools often didn't use SQL, but another database language (usually not fully relational).

A big complaint against using a relational database in applications that need a small footprint or simplified install path is the lack of compact and easy-to-integrate libraries. How much does the SQL language contribute to this situation? Would a better or more compact RelationalLanguage help? Would a reduced subset of SQL help this, or would that be too limiting?

SQL has a lot of clauses, but it's not that hard to parse. The defects of SQL syntax have far more to do with what the SQL programmer has to write, than with implementing an SQL parser -- although obviously a smaller simpler language is relatively easier to implement a parser for.

Regardless of the language syntax, implementing relational semantics efficiently is the more difficult part, by far.

I am not quite sure what you mean. It is true that the earlier tools had languages integrated with the database, sort of like Transact-SQL and PL/SQL, but the issue being described here has more to do with application packaging than language ease-of-use.

Then there's lots of confusion to be straightened out. I thought you were talking about (as is probably obvious by now) the difficulty of implementing an SQL parser, in part because of the above phrase "some also suggest that the SQL language is the culprit because of its large and complex grammar". So you're not talking about that, and not about language ease of use. You're only talking about a small footprint in the application package??? Why is that suggested to be the issue???