Tql Design Goals

Top's Query Language (AKA "SMEQL", or SmeQl in wiki-speak)

Goals Influencing TQL Design

A query language well-suited to application programming, such as dynamic query generation.
- Facilitated by: Independent "functions" (FunctionalProgramming) style so that name-spaces don't become intermingled or too large to manage[1]. This also allows named references (optionally) instead of direct nesting.
Potential to be implemented as direct API's in most languages with little or no modification from the "direct" query language. This would allow it to be implemented both as a BigIron query language (passing query strings) and as a NimbleDatabase set of direct API's with little or no modification of the query language between them.
- Facilitated by: Simple functional style with three and only three clear-cut parameter "types".
- Facilitated by: Quoted expressions. (See TqlOverloading)
- So far this has been the trickiest goal to achieve and may require some compromises.
Meta-abilities to make "self-calculating-queries" and meta-programming easier.
- Facilitated by: Column Tables
- Facilitated by: Small name-space granularity (see above)
- Facilitated by: "Run" command which can "execute" a query list table (currently in speculative status)
DBA extendable
- Facilitated by: Functional style and 3 simple parameter "types". Adding a new operation is a library addition instead of a syntax (key-word) addition.
- Facilitated by: Column Tables, which allow repeated patterns of information to be supplied without creating new syntax.
Idiom Reuse - Uses tables instead of additional or "extra" constructs such as arrays, complex DDL language statements, and column "list" expressions/processing, keeping the language simpler by reusing what's already there.
- Example: we can use the same (traditionally) row-oriented operations to say "pick or show all columns of table X except columns A and B." There is not a different row-oriented filtering/processing syntax or command set compared to column filtering/processing. (It may be convenient to add shortcut syntax for one or the other, but the "long" way is always available for more advanced or extensive uses.)
Attempt not to over-dictate the "domain math" and typing system (or lack of). This makes it easier to adapt to a variety of domains and to existing RDBMS vendors and brands. Unlike RelProject, SmeQl does not intend to discard existing RDBMS engines. (A default or "suggested" expression syntax and operations may be still be provided in the future, probably influenced by SQL standard(s) for familiarity.)
Statement Granularity Flexibility
- One can use it in a heavily "reduced" form, as described in ListAndSingleOperatorExplicitnessPattern, or combine the elements into one or few "big" expressions (similar to current SQL).

Re: "over-dictate domain math"

Could you identify in the RelProject literature where it intends to "discard existing RDBMS engines", particularly as integrating it with existing RDBMses and the strategies required to do so have been an explicit topic here, in which you have participated?

It's from memory, so I cannot confirm it at this point. I'll have to get back to you.

Why I find TQL/SMEQL better than TutorialDee:

Simpler meta model for column list processing.
Simpler syntax:
- All table operations are prefix. D's infix complicates the syntax.
  - Prefix allows parameters to be added in the future or optionally. Infix makes such more difficult. (Named parameters are the most flexible, but have their own problems.)
  - Quote from TutorialDee topic: "Date and I chose it because we thought it was better for teaching purposes, but we have had cause to regret it and would probably switch to prefix notation if we could start again from scratch. -- HughDarwen" [identity not verified, emphasis added]
  - Doesn't have "extra" language features such as arrays, because tables are used instead.
- Allows a close facsimile of the query language to be implemented imperatively in any app language that supports user-defined or library functions or methods. Thus, there would be less mental rethink and less editing to go from local client thin-engine versions of the DB to BigIron versions. ("One big string" would also perhaps be possible on thin-client rather than multi-statement.)
- Easier to define user-defined table operations since there are less syntax element variations.
Designed to co-exist with existing RDBMS brands and vendors, not replace them. It does not attempt to be a GodLanguage.

Some suggest that since Tutorial-D is further along, that it be used as a replacement/alternative to SQL instead of SMEQL. However, if we are going to bother to compete with SQL, we might as well get it right before putting all ships behind it. If Tutorial-D needs a syntax rework, then let's rework it. Now is the time.

[1] I find in SQL that auto-generated column lists, such as with QueryByExample, sometimes result in column name collision conflicts when multiple joins are involved. If joins are moved into a separate concern (name-space), such should be less likely.

CategoryTql, TqlRoadmap