Re: What does this NULL mean?

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Wed, 21 Dec 2005 19:00:39 +0100
Message-ID: <43a997ac$0$11064$e4fe514c@news.xs4all.nl>

dawn wrote:
> mountain man wrote:
>

>>David Cressey wrote:

> <snip>
>

>>The time will eventually arrive when
>>the model of the code and the model of the data will be taken
>>under one theoretical umbrella.

>
> Some strands within the s/w development profession have addressed this
> better than others over the years.
>
> I'm also in the process-&-data-are-two-sides-of-the-same-coin camp. If
> you zoom out, you see that we are working with input, processing,
> storage, and output. Data models are obviously required for each of
> these areas and processing is the big picture. You can see the
> processing clearly with input, processing, and output, but it is also
> implied with storage -- it is intended for use so there is an
> interface for input so there can be processing and output. Decisions
> related to data affect process and vice versa -- they are necessarily
> interwoven into a whole.

(OT, considering the eternal NULL in the subject line-)

Yet this is just one of two big picture views of that whole. The other one is capture - data - presentation.

What you (we) put in the middle depends on your concern: are you managing process or data? IMO both views are necessary. Overemphasizing one of them all the time makes one have to limp all the time. Not practical, and leading to unbalanced theories.

> Some db theorists, or worse yet, practitioners, seem to want to
> consider stores without doors or customers. Some people are interested
> in cars without drivers too so they can look at them and admire their
> design. So I can see how this happens, but it is not the type of
> practical approach one needs in the business world.
Received on Wed Dec 21 2005 - 12:00:39 CST