can views/aliases be seen as materialized and hence be used to

[gbrits]

Extreme qubie question incoming: 

I'm reading about aliases and table views (which are aliases). 

Considering I have a lot of queries that always follow the same pattern in the sense that they always have a group over a subset of properties A,B,C. These properties are fixed and known up front. Could I use views to speed up these queries? I.e.: have 7 views each rollup a different subset of properties (A,B,C) and defer to any of the 7 views depending on the query. Would this work and is this common practice? Any caveats?

Moreover, would these views behave like materialized views in the sense that they're calculated once and stored in mem afterwards? 

If so, how does updating the source table influence the views: are the views updated in their entirety on each partial update of the source table or is kdb intelligent enough to only update affected aggregated rows? 

Thanks a bunch, 

Geert

[Nick]

> would these views behave like materialized views in the sense that they're calculated once and stored in mem afterwards

yes

> how does updating the source table influence the views

views are only executed when accessed AND the underlying data has changed

if your data is updating slowly while your access frequency is high - then views would save on many recalculations

alternatively, if your data updates frequently, and your access is infrequent but from different code paths - then the view would also help.

> Any caveats?

the caveat is that the whole query is executed even if one row (column or field) is updated in the dependent variables (table/dict/etc).  in addition, views do not work when you start your q process with a negative port or if you store your data in a directory. ie:

q).jnp.a::.jnp.b
q).jnp.b:1
q).jnp.a
1
q).jnp.b:2
q).jnp.a
1