Re: Database design

From: mAsterdam <mAsterdam_at_vrijdag.org>
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

Up to here I get it. Yes.

 > 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

Original text of this message