On Fri, 11 Aug 2000, Chris Bitmead wrote:
> Stephan Szabo wrote:
>
> > And whatever is done should leave arrays with the same meaning they
> > currently have for people who use them in other ways. I'm almost
> > thinking that we want a set rather than an array here where sets have
> > different semantics that make more sense for this sort of behavior.
> > It just seems to make more sense to me that a set would be indexed
> > by its elements than array, since position is supposed to be meaningful
> > for arrays, and that set(1,2) is equal to the set(2,1) whereas the
> > indexes aren't. Of course, I guess that's not much different from
> > the normalized table case.
>
> Probably a collection rather than a set. No sense in excluding
> duplicates.
Probably not, at least for the referencing thing anyway. (To do this
to a referenced object would require that the values in all elements
of all the sets be unique, not just within one since the spec we're
going with assumes unique key values.)
> What often happens in an ODBMS is that some general purpose collection
> classes are written based on arrays. A simple example would be...
>
> class Set<type> {
> RefArray<type> array;
> }
>
> Where RefArray<Object> gets mapped to something like oid[] in the odbms.
> Then when you want a class that has a set..
>
> class Person {
> Set<Car> owns;
> }
>
> which gets flattened and mapped to
> create table Person (owns oid[]);
>
> The set semantics being enforced by the language bindings.
Right, but doing something like this ri stuff would require some
collection semantics being enforced by the database, since we'd
be treating this array as a set in some cases, even if it wasn't
a set. It might not matter so much for this case, but let's say
that at some point someone wanted to extend general purpose triggers
in some similar fashion. Then it would become important whether
something was a delete or update, and treating an array as a set
in that case would be a bad idea.
