Re: Modelling Considered Harmful

"Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message news:o1h4k2-94q.ln1_at_pluto.downsfam.net...
> David Cressey wrote:
>
> >
> > "Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message
> > news:4v4mj2-92l.ln1_at_pluto.downsfam.net...
> >> I wonder if anybody would care to dispute the thesis that use of the
term
> >> "modelling" with regard to databases does more harm than good.
> >
> > [major snip]
> >
> >> Nor is the meta-data a model. The meta-data for the employees table
> >> does
> >> not model the company, it specifies what information must be recorded
to
> >> conform with law and policy. since meta-data is data, the meta-data is
a
> >> record of what must be recorded. Still no model.
> >>
> >> Agree? Disagree?
> >
> > I disagree. First off, my usage of the term "modelling" with regard to
> > databases does NOT address the issue of whether or not the data in the
> > database is a "model of reality". I don't even want to tackle that one
> > just yet.
>
> It seems you don't disagree, but use the term modelling to describe the
> attempt to design the database. Works for me....
>
> >
> > The value of modelling goes down, as it becomes cheaper to build a
> > database. But the model is still useful, in some ways, that the real
thing
> > is less
> > useful for. Specifically, a model of a database is easier tounderstand
> > than
> > a database itself. Provided that understanding is a trustworthy guide
to
> > the actual database, there is value in that.
>
> This would be an interesting discussion, the value of a model vs. a
working
> sytem. We have made every attempt to bring the price of creating a db +
> system to zero (the ideal), so that we can jump from brainstorming to
demo.
> Customers seem to greatly appreciate this, and find it very easy to work
> through the system and evaluate it as a real thing.

This raises a few comments and questions.

Modelling can be used in support of analysis, not only design. A model is not necessarily a blueprint, although a blueprint can be seen as a certain kind of model.
If modelling as part of design "works for you", then I don't understand your original thesis.

Brainstorming presumably results in some captured outcome, which is input to the "jump from brainstorming to demo".
I'd be curious about the extent to which the result of brainstorming does or does not have the features of a model.

Next, and this is the most important thing to me, when you talk about demoing the db+system, I gather that the db is not a system in its own right, but merely a subsystem of the application. It's not clear to me whether a db that is embedded within a single app benefits from modelling in the same way that a db intended for sharing data between independently developed apps benefits.

Finally, understanding the db+system is not the same thing as understanding the db. As you said, this is an interesting discussion, but it's not the central thesis you proposed. It almost seems as if you assume that no one needs to understand the db except the person or automaton that embedded it in the app. I wonder if that's true. Received on Fri Apr 29 2005 - 16:31:26 CEST