Re: bags vs. sets

"Marshall" <marshall.spight_at_gmail.com> wrote in message news:1179264037.020520.50770_at_p77g2000hsh.googlegroups.com...
> We regularly deride SQL for using bags rather than sets.
> Now, I get many of the reasons we point and laugh at SQL,
> but I'm not so clear on this one.
>
> We could have a language that covered sets, bags, and lists.
> We could have a language that used bags as the basic
> collection type and built lists and relations out of that.
> It's not hard: a relation is a bag with a uniqueness constraint.
> A list is a bag with a uniqueness constraint on a column
> that belongs to the natural numbers. (Details glossed over.)
>
> OTOH, I'm less clear how to model a bag with relations.
>
> Bags also show up in things like aggregation. The
> sum of a column of a relation is the fold of + over
> the bag-projection over that column.
>
> Vadim has pointed out that there is a clear progression
> in algebraic properties from set -> bag -> list. But in
> set -> bag, you only give up idempotence. Is that a
> big deal?
>
> I'm not disagreeing necessarily, but I'm not as clear
> on the advantages of sets over bags as I thought I
> was. I have some ideas, but I'd really like to hear
> what y'all have to say.
>
> Discussion welcome.
>
>
> Marshall
>

I'm going to suggest that the implementention in terms of bags rather than relations was, historically, a matter of ease of construction rather than one of usefuleness and power. Relations are a whole lot more useful, in a wide variety of contexts. But SQL tables were far easier to implement than rleations would have been.

In practical terms, it's not as big a deal as the regulars in this ng make it out to be. An SQL table with a primary key has a uniqueness constraint. It behaves like a relation almost all the time.

Likewise, it's been stated that SQL doesn't have a project operator. But SELECT DISTINCT behaves like a project in just about every way that matters. Received on Wed May 16 2007 - 02:57:57 CEST