Re: Arrays and foreign keys

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.

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.