
Boost : 
From: Joachim Achtzehnter (joachim_at_[hidden])
Date: 20021101 13:28:57
Arkadiy Vertleyb wrote:
>
> 1. We can have a column whose type is a table (see code below);
>
> COLUMN(b1, int);
> COLUMN(b2, tablea_type);
> typedef tuple<list<b1, list<b2> > > tupleb_type;
> typedef table<tupleb_type, list<b1> > tableb_type;
I see. My attempt failed because I didn't use the second template
parameter in my table definition. This caused a problem with your default
table implementation, which attempted to compare instances of tablea_type.
> 2. As far as other relations (operators) are concerned, right now we can't
> do this because currently the operators are not default constructible. This
> could be easily fixed.
Ok. We would probably need to provide a default operator< for tables. For
efficiency, this might first compare number of rows, and if equal
recursively compare rows and columns. The print utility function requires
a stream inserter for all column types, so we also need that for tables.
The print function itself may need to get much more complicated to format
its output reasonably.
> 3. Just out of curiosity, how would you use this feature? It might become a
> major advantage of this library over traditional RDBMSs.
Well, I'm not sure how "major" this is.
Basically, on the modellevel Date carefully distinguishes between types,
variables, and values. He abandons the old restriction that limited the
type of columns to basic types. Instead, any type can be used, including a
relation type. In practise, this may not be needed very often, but who
knows. One obvious use for this is to represent repeated values, something
that used to be a nono in the relational world. Now, with a proper
theoretical underpinning, one can do this, although it is not always clear
whether the nested table representation is the most convenient one.
Another possible use, and one in which I have personally some interest, is
in the context of temporal data bases. The validity of a row is in general
a set of time points. With the basic type restriction this is often
represented by an interval, but this causes normalization problems when
one needs to represent a noncontiguous set of time points, which then
requires multiple rows. If time stamps can be sets of intervals, i.e. a
relation type, this problem can be avoided. Of course, such singlecolumn
relations are a little degenerate, and perhaps not the best illustration
of why nested tables might be useful.
Joachim
 work: joachima_at_[hidden] (http://www.netacquire.com) private: joachim_at_[hidden] (http://www.kraut.ca)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk