Re: Relational and multivalue databases

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c10ot4$pev$1_at_news.netins.net...
> OK, I'll bite, but only for the purpose of entertaining myself and others
> who find this amusing.

*sigh* And I thought I was going to be able to resurrect the debate sans flaming. Oh well.

> It is typically considerably easier to query non-1NF structures than to
use
> SQL on anything. Here's a common type of query:
>
> LIST STUDENTS WITH EVERY MAJOR NOT EQUAL "MATH"
>
> Think this easy query through in your typical RDBMS (SQL) implementation.
> This is not an isolated case.

So how would this "look" in Pick? Are your assumptions that a student has multiple majors? Once I see what you're getting at, I (we?) can respond with relational counterparts. This doesn't look especially troubling, even for SQL. I'm assuming (until I hear otherwise) that you'd have a Student relation, a Major relation, and a StudentHasMajor relation. Depending on how you "knew" it was "Math", you could omit the Major relation from your query. Join Student to StudentHasMajor, limit based on major, and project over student ID (or whatever).

In Pick I'm guessing you'd say you have just 1 file, with a list of majors as an attribute. But consider the following: 1. To what would you attach, for example, requirements for a major? Surely a major is more than a piece of text?
2. To what would you attach, for example, the date that the student picked up (or completed!) a major?
3. Do I really need to loop through every student in the file to determine how many math majors there are?

And many such others.

> And it isn't just single fields that can be nested, but fields can be
> grouped together and nested as a "nested function" or "nested relation"
(if
> you prefer).

Can you explain further? What does the grouping mean, and how does a function figure into this?

• Eric