Re: Database design
Date: Fri, 24 Feb 2006 00:09:02 +0100
Message-ID: <43fe4030$0$11066$e4fe514c_at_news.xs4all.nl>
Mark Johnson wrote:
> mAsterdam wrote:
>
>>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?
>
>
> Because that latter requires some design, some scheme for the tables
> which are supposed to reflect relations in the RM, correct?
>
> That is, the tables are supposed to correspond to relations in RM.
You could have tried a different phrasing. I'll just guess an interpretation.
Within the context of databases "tables" is a word from
the domain "dbms, SQL and informal talk about databases".
"relation" is a defined term in RM.
"tables" is AFAIK /not/ part of RM - but I am not a RM specialist.
In informal use, "table" and "relation" roughly map.
> And as you get more deeply committed to that structure, things you
> didn't anticipate in advance threaten to overwhelm any subsequent
> modification?
>
> There is a scheme or design to the tables and their interlinking.
Yep.
> The
> more dependent upon and/or complicated that fixed structure becomes,
> there is the possibility that modification to that structure or design
> become prohibitive, or at least very much prone to error.
Yes. This holds for structures of buildings, cells, musical compositions, and other systems.
>
>>>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.
>
>
> But only to point out that the structure from which RM sought to free
> people, from COBOL or whatever else, was replaced by another equally
> inflexible structure.
I am not a native english speaker. I can guess what the above paragraph says, but I'm not sure. I think it is based on invalid assumptions and a strange mixing of concepts, but due to the (to me) strange way of phrasing I can't be sure wether it really says what I think it does. I will not put much effort into interpreting your strange style anymore. If you value my responses please make your statements in a more accessible way.
> But if one builds a COBOL structure upon it,
> without the interwoven programming, a hierarchy, then perhaps it
> becomes more useful, but in a way, and for creating certain problems
> by that (by violating the fundamentals of RM) which some sought to
> address by a full/materialized path key.
Answering in what your style looks like to me:
Maybe - probably not. But do you, some certainly, in a way agree?
>>>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.
>
>
> Domains. Imagine a graph or chart. Interpolation through points. You
> store the points. But a set of points might itself become a primitive
> by reference. But the initial set of primitives would have to be
> treated in another fashion. Maybe 'true' primitives vs. 'combined'
> primitives. But that's weak. Essentially there are the same, but the
> initial state items would probably require different handling and
> reference than anything constructed from them. Again, because it is a
> practical matter, perhaps any theory must necessarily reflect that, as
> well. But maybe not. I don't know.
Aside: Ah yes - again you delete the essence, and you don't respond to it. That makes conversation very tough. Please change your ways.
My contribution was that there are more points of view
than just the one you gave.
It depends on several things, amongst which the task at hand,
what you /choose/ to see as primitives or combined primitives.
If you can't decide on that, you can't design a database.
A lot of hierachy is in the observer, not in the bare facts.
A related question I was pondering lately:
How are "containment hierarchies" and "organisation hierarchies" different/the same? Received on Fri Feb 24 2006 - 00:09:02 CET