Re: Relational Databases and Their Guts

> If one is speaking quite strictly, then yes. One might expect a fair bit
> of strictness in a .theory group.

Speak strictly, please. After glancing at some of the more .theory stuff on the web, I noticed that while AND is intersection, and OR is a union, that subtract has been completely left out, and so in my own DBMS (not relational), I added subtract. Very very cool.

> To my mind, the best reason to complain about SQL not being relational
> is that it allows duplicates. NULLs are pretty wacky, too.

So, strictly speaking, even though it may not be particularly efficient to implement, instead of a relation of:

company relation
companyid pk
company
street1
street2
city
state
zip

and let street2 be nullable, you would?

company relation
companyid pk
company
city
state
zip

company street relation
streetid pk
companyid pk
order

street relation
streetid
streetname

to allow a company have multiple streets. This avoids the NULL and represents 0 - N streets that a company might have.

But, how would you, in terms of basic relational operations (select, project, etc), create a view st each street is in the same tuple as the company city, state, and zip. This is one area where SQL the language (let alone any implementation of it), falls flat on its face.  Then, even if you did that,
what would you use to represent those attributes that do not have the maximum number of streets defined. Does relational theory require that each tuple have the same number of relations in a domain? Did I say that right? Or, in the interests of pure NULL removal, would the server return a jagged result? Or, should you just have street1, street2 and have a value defined within your schema to represent NONE, which is not the same as NULL (which means unknown). Received on Sun Jun 22 2003 - 14:31:50 CEST