Re: Implementation of boolean types.

Marshall Spight wrote:
> dawn wrote:
> > Marshall Spight wrote:

>
> > > > I agree with that too. In fact, all models and all products are
> > > > flawed, but some are more useful than others, right?
> > >
> > > Sure, I guess. Maybe "limited" is a better word than flawed here.
> >
> > This might be a matter of defining terms. In that the RM is a
> > mathematical model and the mathematics underlying it have been defined
> > in a formal system, etc, we could call the RM correct. The flaws with
> > the RM are introduced in the mapping from "reality" to the model.
> > These flaws limit the usefulness of the model. A model is a
> > mathematical metaphor, so it doesn't tell the entire story accurately.
> > It is flawed in that regard. And then there is the implementation of
> > the model, which is a model of the model, introducing more flaws.
>
> I would say 'abstraction' rather than 'metaphor'.

I'm OK with "abstraction" but I like "metaphor".

> And I don't think
> the word 'flawed' is quite right. For example, the mathematical
> abstraction of addition can be used to make prediction about how
> many of something you'll have when you combine two groups. It is
> always accurate; you never put together two apples and two apples
> and get five apples.

If you have an answer to a question and I have an answer to the same quetion that doesn't mean that we have two answers to the question -- our answers might be the same, so adding one answer to another answer might just give us one answer. I know there are much more fun examples where you would not want to map language to arithmetic the way it sounds, but I'm not coming up with them right now.

Similarly, I could take a proposition like this one:

I topped the pizza crust with sauce, mozzarella, and pepperoni

and model it with a relation

PizzaToppings("pizzaId", "topping")

and then ask my model the question "What topping do I put on after the mozzarella?" It is not that I am using relations that introduces the flaw -- it is that I opted to model it this way, which was not useful for the question I'm asking. So, it is a flaw to use this particular metaphor and, in this case, the metaphor is flawed.

When I modeled this data, I didn't think the order of the ingredients was important, so I did not include that in the model. I could have modeled that with this relation by adding an ordering number for the topping, but when I copy this pizza as a template for a new one and then need to put sausage on the pizza before the pepperoni, I have to (as opposed to the data model auto functions) renumber the pepperoni because I put something before it. That seems like a bit of a flaw in the model.

I could have modeled this same proposition with

PizzaToppings("pizzaId", "toppings") and declare toppings to be of type "list". SQL-92 might not be happy with that (and we could call that a flaw in this model), but then my model could include an insert-into-list function so I don't have to renumber.

> It it true that addition doesn't tell the whole
> story, but since it does not claim to I don't see how you could
> call it 'flawed.' 'Incomplete' maybe.

In my examples above, it is not addition nor relational theory that is flawed, it is that using addition or relational theory to model reality in these cases is not as useful as using a different model.

I'll address the rest of the message later, since I've rambled on enough already. cheers! --dawn Received on Mon Jul 25 2005 - 01:31:43 CEST