Introducing Calculated Attributes

Published by cce on 2011-03-14

During our work converting SQL queries to HTSQL, we found a need for re-usable query fragments. This week we introduce define() which names a calculated column or parameterized expression.

Basic Usage

Often during query construction, a query fragment may be copied and pasted many times, frequently with minor changes. For example, suppose you want to collect some statistics over a set of courses for each department.

This query has a repeated expression, (course?no>=200&no<400) which represents courses typically taken by sophomores. The query above can be rewritten with define() to remove this redundancy.

In this equivalent, department.define(...) introduces a calculated attribute sophomore of department. This attribute is then used in the subsequent selector. An intended side benefit is that the column header better reflects the content of the column.

In-Place Declaration

Occasionally you want to define a calculated attribute within a local context. The where() function takes two or more arguments. The first argument is the expression to return, the remaining arguments are local attributes. In this manner the example above could be written:

For this case, a nested selection context is created defining the local attribute sophomore after it is used across 4 aggregates.

Here we use infix notation to call the where() function. In HTSQL, any function call f(x,y) could be written x :f y.

Parameterized Attributes

Suppose that one wants to calculate the same 4 statistics for several different types of courses. A naive query would be written:

In this query we calculate 4 statistical evaluations (count, max, min, avg) across 4 sets of courses (freshman, sophomore, junior and senior). Using the define() function to add calculated attributes, this query could be rewritten as:

However, there is still redundancy – we call the same set of four functions several times. This can be addressed with a parameterized attribute, stats.

One really doesn’t need to define attributes for the 4 subsets of courses, however, it helps readability. Currently, the output headers logic hasn’t been updated to handle this construct.

Open Questions

You may want to define stats differently, instead of passing in a table expression, you may want pass two arguments, the start and end of the course number range.

However, this query will complain about an unknown attribute start in the expression ?course?no>=start. This happens since there isn’t a column start in the table course. The attributes start and finish are available in the top-level namespace of the stats definition, but are not accessible in the course namespace.

Our provisional plan is to add a way to search previous namespaces, in which case the query above would be written:

blog comments powered by Disqus