From: Joachim Achtzehnter (joachim_at_[hidden])
Date: 2002-11-01 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 model-level 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 no-no 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 non-contiguous 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 single-column
relations are a little degenerate, and perhaps not the best illustration
of why nested tables might be useful.
-- 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