Re: Modelling Considered Harmful

David Cressey wrote:

>
> "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

>> >> "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

>> >> conform with law and policy.  since meta-data is data, the meta-data
>> >> is

>> >> 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

>> > is less
>> > useful for.  Specifically, a model of a database is easier tounderstand
>> > than
>> > a database itself.  Provided that understanding is a trustworthy guide

>> > the actual database,  there is value in that.
>>
>> This would be an interesting discussion, the value of a model vs. a

>> 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

>> Customers seem to greatly appreciate this, and find it very easy to work
>> through the system and evaluate it as a real thing.

The "works for me" is in the use of the term "model" for a description of a database that is not itself the database. The original thesis is that the working database itself is not a model of reality, but is just record-keeping.

>
> 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.

I have to segue a little bit to talk about how we develop. We use the chain of events:

PROCESS: Brainstorming PRODUCES human notes PROCESS: Analysis (of notes) PRODUCES specification

Then we put the spec into our builder and it produces a complete working app, with a page that documents the spec that was used to build it.

At this point we ask two questions: 1) is the table design complete and correct? 2) Will the stock libraries suffice for the UI?

As we answer the question, we modify the text-file spec and rerun the build. We may also tweak the UI libraries or add custom UI screens. When there is nothing left to do, we are done.

Sharing data between apps boils down to imports and exports, whether they are XML RPC, inserts to an inbox, or papyrus scrolls. We define those the same we define the app, as data specifications.

>
> Finally, understanding the db+system is not the same thing as
> understanding
> the db.

Yes it is. All business rules resolve to database specifications.

The app must be subordinate to the needs of the db, not the other way around.

> 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.

I do not assume that. I simply say that you don't have to "model" it to understand it. If it were just as easy to build it, why not just build it? And of course the original thesis was that once its built, its a record-keeping system, not a model.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)