Re: TRM and sorts

#1

On 5 sep, 04:22, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:

Quote:

I wonder if anybody here has spent much time thinking about the
practicalities of the "trans-relational model"?
I did. throughouly. I have implemented an assembly disk only db core

supporting basic domain operations (union, intersection, division)
with select and insert's (*not* in the traditional sql sense)

Quote:

I can see its value for joins that don't involve projections of
relations that have a great many attributes, however it seems to assume
that all "tables" are pre-sorted
Not exactly. In TRM, only physical data layer is sorted in several

orders and because TRM does make a clean separation between data and
physical layers, *tables* (or R-tables) are not in the physical layer
aymore.

Quote:

(which for some apps I think is a
reasonable assumption) and since "ORDERing" often involves permutations
of attributes, I think that any implementation that supports ordering on
multiple attributes must either pre-sort every permutation of attributes
or implement the equivalent of a run-time sort.
paul,

TRM is the closest possible implementation of what might be an
independence between physical and logical layers. in TRM, the
predetermined *physical* pre-order of data serves the purpose of
allowing a nondeterministic logical odering of a specific R-Table (I
apologize, I just do not like using the term table). R-Tables are run
time built and their order is determined only through memory adresses
permutations. Therefore, one could say that the main advantage of the
computing model is that *logical* representation of data is indeed
sorted in several orders *almost* simultaneously.

Quote:

Sometimes I wonder if this is one reason why it might be thought
deficient. I'm curious as to what others here might condider practical
deficiencies.
Quite frankly I do not think order is a major drawback that could make

TRM deficient . From the experience I had in the last years, the main
drawback I have found is that it requires more mathematical tools to
support some undefined areas of TRM where basic computing operations
(permutations and combinations) are not sufficient anymore to
implement relational algebra concepts. For instance, at the moment I
am considering using vectorial mahematical tools to support the
implementation of run time domains.

Froe the results I have obtained, I can tell that TRM is the closest
computing model we have to what maybe some day a relational system but
that it requires much more time and effort to do the necessay math to
improve it. I believe the hastiness of Tarin to exploit it
commercially due to its obvious supriority over traditional direct
image is what caused its initial failure. IMHO.

Quote:

p

#2

On Sep 8, 2:22 am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:

Quote:

Cimode wrote:

...

Quite frankly I do not think order is a major drawback that could make
TRM deficient . From the experience I had in the last years, the main
drawback I have found is that it requires more mathematical tools to
support some undefined areas of TRM where basic computing operations
(permutations and combinations) are not sufficient anymore to
implement relational algebra concepts. For instance, at the moment I
am considering using vectorial mahematical tools to support the
implementation of run time domains.
...

just my attitude, but I think lack of ordering or grouping support is
right up there with lack of transitive closure logic as a most
unfortunate omission. maybe that goes back to the times when I couldn't
understand why either the biggest number or the smallest number wasn't
printed first on the 1403 fan-fold pages, preferably the largest
absolute number first AFAIWC. my attitude is probably completely
psychological and maybe pathological too as far as some are concerned.
can't give conventional, aka current, justification for that, sorry!

p
I kind of understand (and sympathize) to what you are refering to. I

believe that neither transitive closure nor unordered set nature could
be sufficiently clarified through a computing model definition (namely
TRM) without a anterior more explicit definition of unique identifiers
within RM (meaning with abstract mathematical tools other than
algebra). As long as such bricks are still missing at conceptual
level of RM, I hardly see any opportunity to imagine a computing model
that could help into solving such problem. I also hardly see any
opportunity of formulating a viable solution only through
experimentation of TRM. In other words, problem of transitive closure
must be solved in RM first before we may be able to experiment it in
some computing model such as TRM.

Sincerely hoping that will make sense.

I am afraid it would be simplyistic on my part to attempt definition
on this NG of the concepts

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Re: TRM and sorts

comp.databases.theory comp.databases.theory

Re: TRM and sorts - 09-07-2007 , 06:29 PM

Re: TRM and sorts - 09-10-2007 , 04:08 AM