Tql Roadmap

Top's QueryLanguage (TQL) Proposal

The TqlName has not been decided yet, partly because "TQL" is already taken. SMEQL (pronounced Smeagol and wiki-tized to SmeQl) is one contender. SMEQL stands for Structured Meta-Enabled Query Language.

(Let me dream.)


TopMind is working on a relational language to overcome SqlFlaws. It has a BusinessSystemTwelve-like functional style (FunctionalProgramming) that makes it easier to break queries into digestible chunks, avoiding the "run-on" nature of SQL. It differs from BS-12 in that the arguments can only be one of 3 things:

  1. Tables - virtual or real
  2. Expressions that return scalars or tables
  3. Scalars (values like numbers or strings)

Being only one of 3 three things simplifies the implementation, understanding, flexibility, and extensibility of the language. If new constructs are added in the future, it usually does not require changing the language, only creating new operations with parameters that fit the standard. It thus is a library addition instead of a language addition. The syntax also makes it easier to implement the operations as regular functions or methods of "typical" programming languages. TopMind has not seen this ability in other query languages. The general syntax is:

  resultTable = operation(parameters.....)
One can optionally nest these:

  t1 = foo(blah)
  t2 = bar(t1, zog)

Into:

t2 = bar(foo(blah), zog)
Note that the final result set name is not needed. Thus, one could type:

  bar(foo(blah), zog)
However, most examples here will not use the nested form. The intermediate tables should be considered virtual tables. They are not assumed to be "saved" unless explicitly requested. They are merely a way to linguistically reference query "chunks". An optimizer may even opt to skip the internal creation of parts or all of virtual tables as long as the final result is the same. (SQL provides views and/or nested SELECT's for a similar purpose, but these suffer the awkward ThickBreadSmell, cannot be reused in the same statement, or require DBA intervention.)

Key Language Features: Sample Code: Discussion: Issues Postponed or Not Fully Addressed Contributors to the TQL pages:

Why differentiate scalars and tables? If a scalar is a 1 row, 1 column table then you don't need to worry about what you're dropping where, because EverythingIsA table. This could rapidly turn into a Lisp dialect if you aren't careful ;)

Perhaps this relates to the syntax issue raised in TqlOverloading. A TQL operation has to know what kind of parameters it is getting. If a parameter can be more than one of the 3 kinds of things listed above, then the syntax may grow complicated.

Perhaps conversion functions can be provided to convert from one kind to the other so that a reliance on type overloading isn't necessary. I would like to explore some UseCases first. --top


Comments about implementation moved to TqlImplementation.
Type Issues


The Hadoop "Pig" query language breaks queries into SmeQl-like chunks, and thus has a similar granularity.


Would that be in the family as NoSql (pronounced Nazgul)?

The NoSql movement seems to be more against "Oracle-style" database engines, not so much SQL the language.


See also: RelationalLanguage, FunctionalProgrammingLanguage
CategoryTql CategoryQueryLanguage CategorySpeculative

EditText of this page (last edited June 27, 2013) or FindPage with title or text search