Re: Advice on SQL and records

Marshall Spight wrote:
> fran_beta_at_hotmail.com wrote:
> >
> > I guess the problem is "what exactly are the records in
> > 'StudentClasses'"?
>
> The term "records" isn't a great one, as it promotes record-based
> thinking. Set-based thinking is more native to the relational world.
>

So is this the term you'd use for a all of the data pertinent to one entity in a table?

Would "array" be an equally good term, and if not (perhaps the range of contexts in which it is used) why not?

> "A language that doesn't affect the way you think about programming,
> is not worth knowing." -- Alan Perlis
>
> SQL, flaws and all, will change the way you think about programming
> if you bother to really learn it. Most don't; instead they just try
> to find a way to map their current preferred language/way of thinking
> onto it, find it doesn't fit very well, and judge it harshly. Imagine
> a 1960s FORTRAN programmer being unfrozen and trying to learn Java.
> He would quickly assume it was inferior because it lacks GOTO. Try
> to get over the hump; SQL has a lot to offer.
>

I'd love to learn all this stuff properly. It's a real gap in my grasp of the content. Instead, I've been given the bare bones and am trying to piece them together into a coherent whole like some obsessive archaeologist.

>
> > It seems implicit from what you say that StudentClasses includes all
> > ClassID records AND all StudentID records, whereas I assume that only
> > ClassID records would be in there.
>
> Neither one. The StudentClasses table has only two attributes: a student
> id
> and a class id. It exists to model what students are in what classes,
> and
> not any facts about students or classes per se.
>
>

OK

> > Is it the case that records contain records?
>
> Surprisingly, no.
>
>
> Marshall

So how would you go about answering which table was likely to contain the most records or "sets"?

Fran Received on Mon Aug 22 2005 - 06:27:03 CEST