From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2002-11-01 14:27:06
"Joachim Achtzehnter" <joachim_at_[hidden]> wrote in message
> 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.
Right. If the sort list is not specified, we assume that the table is
sorted on all fields in the field list, and therefore we need operator< (or,
to be more acurate, std::less) for all the fields. I avoided it by
specifying the sort list explicitly.
> > 2. As far as other relations (operators) are concerned, right now we
> > do this because currently the operators are not default constructible.
> > 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.
Why? Do we really need to sort on tables?
> 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.
Streaming is the issue that we have to synchronize with the upcomming
serialization library. We knew that we would need streaming, for both
persistence and networking, so we implemented some basic version of it --
the utility that streams a tuple (provided all the fields are streamable).
We stopped there, assumming that to serialize a relation is a trivial task
as long as the tuple is serializable.
The print utility function serves mostly for debugging purposes. But I do
agree with you that it doesn't handle this case correctly. Unfortunately,
this is not the only case it has a problem with. Overall, I agree that it
needs to be enhanced, to what extent -- this is another question.
> > 3. Just out of curiosity, how would you use this feature? It might
> > 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.
I can't claim I understand all of it, but just keep in mind that you might
not have to use a table here. Just a pointer (or shared pointer) to
std::vector may be enough.
Averall, this was a good test of our statement that ANY type can be in a
field. How was your experience with the library otherwise? Have you been
able to build the tests? What compiler are you using?
Please feel free to ask any further questions, and provide any comments.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk