I should also clarify that I don't see SQL as *a* language but rather as a family of languages. Each actual SQL language in the family is whatever some particular SQL DBMS actually implements and how it behaves. So eg "SQLite SQL" is *a* SQL language, with generally a distinct version for each SQLite release. Then "SQLite SQL" is a considerably simpler language than say "Oracle SQL" or what have you. But I see this discussion about a SQL alternative to be relative to the SQL language family in general, which in my mind is its use case, rather than just SQLite specifically. That also means that the SQL alternative would in practice be a language family itself, assuming multiple implementations, though hopefully they would be a lot more consistent with each other than the SQL family languages have ended up being. -- Darren Duncan
On 2015-06-18 1:27 PM, Darren Duncan wrote: > On 2015-06-18 3:35 AM, ajm at zator.com wrote: >> Darren: >> >> Maybe you're right. But to that relationship of "goodness" that would be >> desirable, perhaps we should add a few drops of pragmatism. Experience shows >> that in many cases, the perfect is the enemy of the good, and despite a >> disrupting transition (refusing the bad legacy of SQL) can avoid some >> drawbacks, however a non-disrupting evolution, has the advantage of being >> more >> easily accepted and assimilated by the users, as has happened before. > > I'm not proposing "perfect" at all, but rather I don't agree that the best > solution is to be perfectly backwards-compatible with SQL such that all SQL > code > is also valid code in the new language, as you are proposing. > > I don't think you realize just how complicated SQL as a whole is. What SQLite > implements is just a small subset of it. Just the core part of the ISO SQL > 9075-2:2011 language spec is about 1466 pages long and that leaves a lot out. > Besides this, various dozens SQL DBMS vendors have their own proprietary > additions or differences. Even just taking a subset an extending that, isn't > innovating beyond existing current practices, and we have dozens of those > variants. > > A lot of existing popular application languages have a much smaller language > complexity than SQL does. > > What I'm proposing as good is something more comparable in complexity to > those, > while still being able to express everything you can in SQL without any > greater > verbosity or difficulty in understanding. > > One primary way to achieve that is to represent nearly all operators / actions > using generic routine call syntax rather than custom syntax per operator, > which > is what languages like C, C++, C#, Java, etc do. For such as these, the > language itself is fairly small, and most of the details are just in the > libraries. SQL supports libraries too, eg stored procedures/functions/etc but > an inordinately large number of built-ins are not expressed in those terms. > > It is very reasonable to have generic syntax function calls to represent the > various parts of a SQL SELECT for example, similar to how we have array or set > or whatever routines in application languages today. That makes the syntax > relatively simple and user-extensible, and it by no means prevents a DBMS from > doing any query rewriting or optimizing or rearranging whatever it wants to do > to implement the over-all expression efficiently, in fact a DBMS may even have > an easier time of it. > > Don't get me wrong, a new language can have these qualities and still look > familiar to SQL users, its not like it means using APL etc. > > -- Darren Duncan > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
