Re: [boost] Re: relational table as an STL container -- any interest?

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.

Joachim

-- 
work:     joachima_at_[hidden]   (http://www.netacquire.com)
private:  joachim_at_[hidden]          (http://www.kraut.ca)