Re: So what's null then if it's not nothing?

Alexandr Savinov wrote:
> David Portas schrieb:

>> Alexandr Savinov wrote:

And this is bad because ... ?

> Another reason is that we may well lack information about our problem
> domain so that we cannot guarantee that objects will have all attributes
> assinged to them in our schema. For example, assume that we have table
> Persons with the company employees. But today we had to hire a Marsian.
> Are you sure that it will have such a characteristics as sex?

No.

Being an employee has consequences. Does the sex of an employee have consequences? - e.g. for the rights and duties of the employees at your company, or it may (maybe partly) determine the contents of chrismas presents.
If so we should reconsider the sex attribute when hiring employees who do not have one. We should talk with the martians about what they think about these consequences. If not it was a mistake to have it in the database to begin with.

> Maybe if
> we ask him then it will answer that he does not understand what we are
> talking about. Should we then take Marsians into account when we count
> the number of women and men in the company?
>
> And the third reason is theoretical. Independent what happens in
> practice we would like our theory (data model) be general enough to
> explain very exotic cases. This inclues such extremes as one wide table
> with all possible columns and many narrow tables with a few columns.

Say we have registrations for cars and for boats. Along comes a carboat. In our database we'll see a car and a boat - maybe a note at both referring to the other.
Along comes another carboat, and yet another. Only when it becomes to cumbersome to doubly deal with events happening to carboats we'll introduce some way to formally register the fact that the car and the boat are one object - but e.g. its boat.length may very well differ from its car.length due to regulations stating how to measure the length. Received on Thu Nov 17 2005 - 21:44:10 CET