Re: sql views for denomalizing

Eric Junkermann wrote:
> In message <1123119770.710775.24360_at_g47g2000cwa.googlegroups.com>, dawn
> <dawnwolthuis_at_gmail.com> writes
> >Eric Junkermann wrote:
>
> <snip/>
>
> >> The user interface described is clear and simple, I like it.
> >>
> >> But then you start talking about storage, which has nothing whatever to
> >> do with interface design, and neither has anything to do with logical
> >> modelling.
> >
> >I'm glad you piped up on that point because I hear hints of similar
> >perspectives from others and I haven't caught on to what the point is
> >as yet. I'll try to explain better what I'm thinking.
>
> <snip/>
>
> >
> >Think of a hub and spokes architecture where this controller software
> >works with various device services.
> >
>
> You seem to have on-line data storage, off-line data storage, and
> presentation services all connected to a "software hub", and all having
> the same API.

Yes, as it relates to the data model.

> I've never thought of it this way, I've never seen this approach
> articulated before, and, as far as I can tell, I've never seen it used.
> I do see that it is possible, but I would have a lot of thinking to do
> before trying to use it.

that is as fair a response as I could ask

> I think most people view presentation as essentially different from
> storage, so that there are layers with data moving up and down, rather
> than radially to and from a hub.

I think they do too. I see little reason for it. People who work on hci (human-computer interaction) sometimes see the person as the source and sink for data. People working with databases sometimes see the database as the source and the sink. I see data movement.

> Also you seem to view your storage devices as essentially physical,

I have no use for processing data with a storage device that is not physical, do you? Even if there are no-physical entities - spirits, etc - I'm not addressing them with this architecture ;-) but I suspect I could if I knew what you meant.

> even
> though have each of them layered.

Yes, I don't interface directly with any physical device as they all have software wrappers of some sort. Lower level programmers (who are at a higher level than I, just so we understand the use of the term "lower") work directly with physical devices and I interface with their services or services that use their services, or services on top of that even.

> It seems that your main logical model
> is your central API,

yes, yes

> which says to me "programmer-centric",

no, no -- I'm data model centric

> i.e. the
> point I was trying to make originally.
>
> <snip/>
>
> >I do not want to model a tree one way when I'm working with one I-O
> >device service and another with others.
>
> I don't think I want to model a tree, I think a tree is a (possible)
> primitive in a logical model (which I will have to implement eventually,
> but an implementation is not a model).

I'm not tracking with that statement. Would it make sense to you to model a family tree using nodes and edges? Isn't that a reasonable logical model of such data?

> <snip/>
>
> >>
> >> The programmer's view of data is a short-sighted one,
>
> >them's fightin' words, my friend. I could say that someone managing
> >web server software or dbms software each has a very narrow view of the
> >data. Sometimes they even think that there is no other data model api
> >than the ones they provide. It is the software developer that sees that
> >we are modeling data everywhere (and that we should stop doing it so
> >very differently everywhere).
> >
>
> The data has a longer life span than any piece of presentation logic,

If you are suggesting that the average data value has greater longevity than the average constraint or other business logic applied to that data, that might be, but that question doesn't interest me. Such code is data too (in a source code repository, for example). Why is that relevant? Some data are more fluid than other data. Metadata, including code related to data, is essential to data going into and out of a repository. Data in a lock box with no processes is worthless.

> and the data represents a set of true facts (tautology used deliberately
> for emphasis),

a set of true propositions is nothing if not for processes that can extract those truths and pass them to people who need them. It is the entirety of the system -- data values, schema, metadata, code, ui specs, ... that has value.

> and one particular "storage device" (to use your concept
> from above) must be the primary (hence authoritative) repository of the
> data.

So the source of the data are not the people, but the machine, eh? If a database offers up propositions that are in conflict with people who are experts in a particular area, where would you go to resolve this difference? I would go to people, the source of such data and not to the machine.

> What I am saying is that it is all too easy to forget this when
> programming, so it happens a lot.

I think I'm catching the drift of this database-centric line of reasoning. I don't see these data values as being so separate from the vessels that move them, but I will think about this more. Thanks. --dawn

> Eric
> --
> Eric Junkermann
Received on Fri Aug 05 2005 - 00:01:53 CEST