Re: Database design
Date: Thu, 23 Feb 2006 19:40:03 +0100
Message-ID: <43fe013a$0$11062$e4fe514c_at_news.xs4all.nl>
Mark Johnson wrote:
> mAsterdam wrote:
>>The database way (nothing RM specific here) works ok >>for a lot of similar facts (same or similar facttypes). >>It doesn't work well for dissimilar facts (a lot of >>different facttypes) or facttypes you don't know in advance.
> Because that latter requires some design, some scheme
> for the tables which are supposed to correct? > reflect relations in the RM, correct?
This I can't parse. What are you saying?
> And as you
> get more deeply committed to that structure, things you didn't
> anticipate in advance threaten to overwhelm any subsequent
> modification?
Bad design can be quite costly indeed.
>>Mark Johnson wrote: >> >>>mAsterdam wrote: >>> >>>>Mark Johnson wrote:
>
>>>>time you decide what you consider atomic, or something containing other >>>>things, or both.
>
>
>>>I might tend to agree with Savinov, that atoms/elements are those >>>things analogous to primitives; tones, spheres, rotation, a single >>>controller scalar, and so on. But fundamentally, these are components >>>themselves. Maybe it's the distinction between components and >>>initial/primitives components.
>
>
>>A few seconds ago I thought you got the point, now I have >>doubts again. /You/ (the designer) decide >>what is primitive and what isn't, it is not >>a given thing.
>
>
> At some point, and I think I agreed with him, it is. The tone is a
> primitive. It is atomic and indivisible.
That is one point of view.
POV 2: Frequency, amplitude envelope, harmonic content, phase.
POV 3: It is made of wave patterns of vibrating air.
> It is atomic and indivisible. It is represented perhaps
> with more than a single scalar, rather a tuple if you like. But as a
> practical matter, it would be treated differently than any subsequent
> component into which it was incorporated.
>
> As I said:
>
>
>>>>>any item can be a component, and has some limited meaning and utility >>>>>by itself, by its very definition. The tone middle-C is still >>>>>middle-C. In the same example, I can see, however, that one might wish >>>>>to distinguish such elementary building blocks as a controller scalar >>>> >>>>>from a full run of such. Still, I don't know. I suppose as a practical >>>> >>>>>matter, one would only reference a component but have to refer to >>>>>items in a different fashion.
>
>
>>>>It depends on which things in the world you label 'Entity' >>>>(definition: thing of interest).
>
>
>>>And I suppose to recall some of the response to this in this and other >>>threads, to some degree - to some degree - it might seem rather >>>subjective and so somewhat irrelevant. But sometimes definitions can >>>matter, particularly in slurry of multiple contexts and senses.
>
>
>>"rather subjective and so somewhat irrelevant."
>
>
>>- and yet the only foundation.
>
>
> One also has to remember the overloaded meaning of words, the multiple
> definitions, and multiple terms applied to much the same things, all
> depending. Perhaps what they think unimportant is something else,
> entirely. They think they're talking about the same thing, even, and
> are not.
"They" being ...? Received on Thu Feb 23 2006 - 19:40:03 CET