Possible bridges between OO programming proponents and relational model
Cimode
*behavior* into components (named classes). This caracteristics is
often presented as being a differentiation of relational model where no
such thing really exists (and in fact is not necessary). In a word, In
OO approach (for whatever it may rely on), one of the main limitation
of relational model would be not to allow its elementary components to
emulate elementary predefined processes (transformations for instance).
I have the impression, there is a concept, unbearable to some
programmers that data management systems can not be anything else than
a mechanized set of tool that could help structuring data for human
interpretation. On that standpoint, relational model components
reflect an approximation of *meaning* concept as being a contextualized
and specific combination of constraints, business rules to make
predefined inferences about that data for preparing interpretation.
Processes are defined only according to specifically defined
inferences. On the other side, OO approach seems to advocate that some
level of elementary process autonomy will end up creating *some* form
of intelligence thanks to some cumulative effect. On such perspective,
I start suspecting all debate stating behavior lacking in the
relational model is an empty unfounded attempt of some IT professional
to project their scifi fantasies about what system could do and what
they can actually do in a realistic manner.
On the other side, some OO advocates state that OO approach brings some
features that would seem to better implementations of subtype and
supertypes features through inheritance as well as a better in memory
physical handling of non primitive types than what we are accustomed to
with traditional SQL implementations.
I am curious about your opinion about this matter as this is a new
board for me. (Sorry if you have noticed some english errors as it is
not my native language) so bear with me please.
Kenneth Downs
> I noticed a recurring commercial argumentation about creating
> *behavior* into components (named classes). This caracteristics is
> often presented as being a differentiation of relational model where no
>
> such thing really exists (and in fact is not necessary). In a word, In
>
> OO approach (for whatever it may rely on), one of the main limitation
> of relational model would be not to allow its elementary components to
> emulate elementary predefined processes (transformations for instance).
You don't have to worry all that much about what the relational model allows
or doesn't allow. As anybody here can tell you, there are no pure
relational databases in the Real World.
What we have is quasi-relational table-based systems that in fact can handle
processes very well.
The problem is in how you think about the process, especially
transformations. All transformations and processes can be mapped into
simple precise definitions of what values should be written to what columns
of what tables. In other words, processes resolve to database
specifications. If you can specify it, you can code it.
When trying to specify processes in terms of tables, the relational concepts
of unique key and foreign key come in very handy for specifying how data
should be moved from place to place as it is transformed. Adding basic
formulas finishes it off.
So sure, the RM can't do it, but who cares? Table-centric systems can.
--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)
Cimode
<<You don't have to worry all that much about what the relational model
allows
or doesn't allow. As anybody here can tell you, there are no pure
relational databases in the Real World. >>I am puzzled by this
statement...Everything in my experience teaches me that the current SQL
implementation have recurring problems because they actuall y do not
support correctly relational concepts...
<<What we have is quasi-relational table-based systems that in fact can
handle
processes very well. >>What do you exactly mean by handling processes
very well? Most systems I face dayly, present grave performance and
administration problems that could be avoided if rules dictated by
normalization were respected...
<<Table-centric systems can. >>I see...What exactly are table centric
systems...Do you mean SQL based systems (ORACLE, DB2, SQL Server)
My concern is about how OO mechanisms could be utilized to allow better
physical implementation of relational concepts...Is Java a potentially
language than SQL for data manipulation, data definition (or
both)...Thanks for your input...
Kenneth Downs
> Thanks for the response...
>
> <<You don't have to worry all that much about what the relational model
> allows
> or doesn't allow. As anybody here can tell you, there are no pure
> relational databases in the Real World. >>
> I am puzzled by this
> statement...Everything in my experience teaches me that the current SQL
> implementation have recurring problems because they actuall y do not
> support correctly relational concepts...
Like what problems? Can you give a few examples?
>
> <<What we have is quasi-relational table-based systems that in fact can
> handle
> processes very well. >>
> What do you exactly mean by handling processes
> very well? Most systems I face dayly, present grave performance and
> administration problems that could be avoided if rules dictated by
> normalization were respected...
You clipped it all out. I said that being able to specify transformations
and automations would do the trick. That's how we do it here at SDS.
There are some exceptions that require hoop-jumping, but they are thankfully
very rare.
>
> <<Table-centric systems can. >>I see...What exactly are table centric
> systems...Do you mean SQL based systems (ORACLE, DB2, SQL Server)
>
> My concern is about how OO mechanisms could be utilized to allow better
> physical implementation of relational concepts...Is Java a potentially
> language than SQL for data manipulation, data definition (or
> both)...Thanks for your input...
I went the other way myself, putting more abilities into the server and
using less OO, and it has served our company and our customers well.
Cheers,
Cimode
redundancy which create lots of performance bottlenecks...For instance,
people allow NULL values into tables which create the need to add
additional excluding conditions (IS NULL, IS NOT NULL...) into select
procedures to get correct results in COUNT statements. As a
consequence, they degrade performance (both response time and
througput) when they do that...If NULL were not allowed in the first
place, then these additional conditions would not be used...
<<I said that being able to specify transformations
> and automations would do the trick.
There are some exceptions that require hoop-jumping, but they are
thankfully
very rare.
>> Could you give few examples to illustrate what you mean by transformations and automations? and the exceptions you are refering to?
<<I went the other way myself, putting more abilities into the server
and
> using less OO, and it has served our company and our customers well>>
I don't believe we are speaking about the same thing..
It seems you are refering to centralizing processes into server side
which is probably more practical in all senses...I was however refering
to using OO mechanisms and features as a replacement to SQL (as a
server side language) for data manipulation and definition...
Thanks for your input...
Cimode
incapability to implement the multidimensionality of relvars. The main
reason seems to be the lack of independence between the physical layer
and logical layer the represent the data. In several DBMS tuples are
right away on disk projections imposing that all tables are considered
bidimensional. In fact, it should not be the case because a
bidimensional RTable is only a *representation* of some entity. An
interesting analogy that may help communication, is Rubi's Cube (3
dimensional): looking at one face of the cube it's only one possible
representation of the cube (being the relvar)...Thank you for bringing
some insight (flamers please refrain) onto how OO mechanism may help
separate the logical operation (in memory) from physical layer...
Subject is launched...
Bob Badour
> One of the main current flaws of current SQL DBMS systems is their
> incapability to implement the multidimensionality of relvars.
With all due respect, what you wrote is nonsense. An SQL table of degree
N (ie. with N columns) has N dimensions.
Alfredo Novoa
> One of the main current flaws of current SQL DBMS systems is their
> incapability to implement the multidimensionality of relvars.
This does not make any sense, the dimension of a relvar is the number
of attributes.
> The main
> reason seems to be the lack of independence between the physical layer
> and logical layer the represent the data. In several DBMS tuples are
> right away on disk projections imposing that all tables are considered
> bidimensional.
The only way to do this is to force all logical tables to have two
attributes.
> In fact, it should not be the case because a
> bidimensional RTable is only a *representation* of some entity. An
> interesting analogy that may help communication, is Rubi's Cube (3
> dimensional): looking at one face of the cube it's only one possible
> representation of the cube (being the relvar)
I suppose that you know how to represent a cube with a table.
> some insight (flamers please refrain) onto how OO mechanism may help
> separate the logical operation (in memory) from physical layer...
Are you suggesting that the memory is less physical than the disk?
Regards
Alfredo
Cimode
confusion but I should rephrase otherwise for the sake of clarity.
(Again English is not my native language so expressing consensual
terminology in english is difficult to me. As Fabian PASCAL declared
"commitment" to precise terminology is crucial into abording relational
model matters).
First, I make a clear distinction between SQL and its current
proprietary implementations(DB2, ORACLE, SQL Server...). As you know,
several features specified in standard (SQL92) have not been
implemented, creating lots of overhead work at applicative level into
guaranteing integrity at physical implementation time (ex:create table)
which makes SQL implementations and therefore SQL DBMS's unefficient.
Of course, there is no better alternative as SQL based systems are
still the best we have.
Second, I make a clear distinction between SQL tables *as implemented
currently* and relvars (called also R-tables). On that standpoint, I
do not see how are current *physical* implementations of SQL are
multidimensional when all the ones I know (but I only know the main
exposed above) use direct image storage of tuple physical
implementation.(totally defeating relational independence between
logical and physical layer). So I am curious to why, presicely you are
saying that a SQL table is multidimensional. My guess is that you are
refering to what SQL should be as opposed as to how it is implemented.
On that case, I agree with that statement. On the opposite case
Third, the hidden agenda of this thread is to focus discussion on
in-memory logic projection of relvars assuming total independence
between disk based storage and representation of R-Tables at runtime.
As you also know current SQL implementations (and SQL implemented
tables) are direct projection of physically static (generally
bidimensional) representation of tuples. On such perspective, the
little education I have about OO mechanisms encourages me to seek
discussion with OO audience to educate myself about possibilities OO
can offer to drive a better relational implementation.
So no. I do not believe what I am writing is nonsense. So I will
stick to what I have declared previously. Do not hesitate to
contradict me if you believe I missed some points. Thank you for your
implication in this thread.
Bob Badour
> Thank you for your feedback. I do not believe I am making any
> confusion but I should rephrase otherwise for the sake of clarity.
> (Again English is not my native language so expressing consensual
> terminology in english is difficult to me. As Fabian PASCAL declared
> "commitment" to precise terminology is crucial into abording relational
> model matters).
>
> First, I make a clear distinction between SQL and its current
> proprietary implementations(DB2, ORACLE, SQL Server...). As you know,
> several features specified in standard (SQL92) have not been
> implemented, creating lots of overhead work at applicative level into
> guaranteing integrity at physical implementation time (ex:create table)
> which makes SQL implementations and therefore SQL DBMS's unefficient.
> Of course, there is no better alternative as SQL based systems are
> still the best we have.
I am not certain I agree with that last sentence. Of the dbmses that
have widely or deeply penetrated the market, SQL based systems are the
best we have. There may or may not be better alternatives that are
relatively unknown.
> Second, I make a clear distinction between SQL tables *as implemented
> currently* and relvars (called also R-tables). On that standpoint, I
> do not see how are current *physical* implementations of SQL are
> multidimensional when all the ones I know (but I only know the main
> exposed above) use direct image storage of tuple physical
> implementation.(totally defeating relational independence between
> logical and physical layer).
That's a different issue. I agree they provide insufficient physical
independence. However, that does not change the degree of a table and
does not change the fact that the degree is a direct measure of the
dimensions.
So I am curious to why, presicely you are
> saying that a SQL table is multidimensional. My guess is that you are
> refering to what SQL should be as opposed as to how it is implemented.
No, I am referring to both. Consider the following SQL table:
Create table s5 (
x as integer not null
, y as integer not null
, z as integer not null
) primary key (x,y,z);
insert into s5 values(0,0,5);
insert into s5 values(0,0,-5);
insert into s5 values(0,5,0);
insert into s5 values(0,-5,0);
insert into s5 values(5,0,0);
insert into s5 values(-5,0,0);
insert into s5 values(0,3,4);
insert into s5 values(0,3,-4);
insert into s5 values(0,-3,4);
insert into s5 values(0,-3,-4);
insert into s5 values(0,4,3);
insert into s5 values(0,4,-3);
insert into s5 values(0,-4,3);
insert into s5 values(0,-4,-3);
insert into s5 values(3,0,4);
insert into s5 values(3,0,-4);
insert into s5 values(-3,0,4);
insert into s5 values(-3,0,-4);
insert into s5 values(4,0,3);
insert into s5 values(4,0,-3);
insert into s5 values(-4,0,3);
insert into s5 values(-4,0,-3);
insert into s5 values(3,4,0);
insert into s5 values(3,-4,0);
insert into s5 values(-3,4,0);
insert into s5 values(-3,-4,0);
insert into s5 values(4,3,0);
insert into s5 values(4,-3,0);
insert into s5 values(-4,3,0);
insert into s5 values(-4,-3,0);
Regardless of implementation, a sphere of radius 5 has three dimensions
as does the set of integral points on a sphere of radius 5. The table s5
above has degree three and three dimensions: x, y and z.
> On that case, I agree with that statement. On the opposite case
Agreeing with something I never said seems pointless.
> Third, the hidden agenda of this thread is to focus discussion on
> in-memory logic projection of relvars assuming total independence
> between disk based storage and representation of R-Tables at runtime.
> As you also know current SQL implementations (and SQL implemented
> tables) are direct projection of physically static (generally
> bidimensional) representation of tuples.
As a matter of fact, I do not know that because it is in fact not true.
On such perspective, the
> little education I have about OO mechanisms encourages me to seek
> discussion with OO audience to educate myself about possibilities OO
> can offer to drive a better relational implementation.
I think you will find far more fertile ground elsewhere.
> So no. I do not believe what I am writing is nonsense. So I will
> stick to what I have declared previously. Do not hesitate to
> contradict me if you believe I missed some points. Thank you for your
> implication in this thread.
When you write that an SQL table of degree 3 has two dimensions, then
what you write is nonsense regardless of your belief.
Cimode
<< This does not make any sense, the dimension of a relvar is the
number
of attributes.>>Absolutely. but SQL table implementations are not
relvar, just a possible representation of a relvar. Commonly
implemented SQL DBMS Tables are bidimensional.
<< The only way to do this is to force all logical tables to have two
attributes.>>Why is that? What sources makes you believe that?
(Curious about that assertion) Are you refering to Transrelational
Model?
<<I suppose that you know how to represent a cube with a table.>> It is
an analogy used for communication's sake. You misread and
misunderstood my comment. I said that a face of a cube is
bidimensional and is a comparable to what a SQL Table is to a relvar.
(the relvar being a 3 dimensional relvar). This analogy has been used
by DATE and PASCAL and I find it very valid.
<<Are you suggesting that the memory is less physical than the
disk?>>Interesting question but the answer is obviously no. The
argument here is about getting better independence *progressively*
through thinking as to how in-memory representation of relvar could be
more truthful to what a relvar . The question is whether OO in-memory
mechanisms could support such effort. And how?
vc
Cimode wrote:
> Thank you for your feedback.
>
> << This does not make any sense, the dimension of a relvar is the
> number
> of attributes.>>Absolutely. but SQL table implementations are not
> relvar, just a possible representation of a relvar. Commonly
> implemented SQL DBMS Tables are bidimensional.
VAR CUBE RELATION { X REAL, Y REAL, Z REAL}
TABLE CUBE(X REAL, Y REAL, Z REAL)
What's the substantial difference with repect to 'dimensionality' ?
> <<I suppose that you know how to represent a cube with a table.>> It is
> an analogy used for communication's sake. You misread and
> misunderstood my comment. I said that a face of a cube is
> bidimensional and is a comparable to what a SQL Table is to a relvar.
> (the relvar being a 3 dimensional relvar). This analogy has been used
> by DATE and PASCAL and I find it very valid.
See above, and what analogy do you have in mind ?
Cimode
on that? What
do you have in mind?
<<That's a different issue.>>You really think so? I would argue that
it is too closely related to to be ignored.
<<However, that does not change the degree of a table and
does not change the fact that the degree is a direct measure of the
dimensions.>> Yes. So. I have never denied that. This is why I
made a distinction between SQL tables as they are implemented and SQL
tables as they should be represented. Do you have any idea onto how an
in memory SQL table footprint looks like on current SQL DBMS?
<<No, I am referring to both. Consider the following SQL table:>>
I do have the impression we are talking of different things. I do not
disagree with anything you have declared but you totally miss the point
I tried explaining several times .
If you consider that SQL tables in traditional DBMS are
multidimensional because syntaxically seem to be you are placing
yourself exclusively at high level not on in memory level. In which
case I understand better the source of confusion.(which is my mistake,
I should have been more cautious about that).
<<Regardless of implementation, a sphere of radius 5 has three
dimensions
as does the set of integral points on a sphere of radius 5. The table
s5
above has degree three and three dimensions: x, y and z.>>
Yes. That's not the point.
<<As a matter of fact, I do not know that because it is in fact not
true.>>
I don't understand this statement. How can you not know something and
disqualify it as not being true. Could you ellaborate?
<<I think you will find far more fertile ground elsewhere.>>Probably.
Looking at the spirit of most comments I have read in other threads NG,
it seems collaboration is not the main overall drive in this NG. Thank
you for pointing it out.
<< When you write that an SQL table of degree 3 has two dimensions,
then
what you write is nonsense regardless of your belief.>>
I have not written that anywhere (have not used degree). I am curious
however as to *what* exactly makes you believe that I said that.
If you don't mind, I will use your example to clarify:
...Consider the following relvar
T5: x,y,z
...then consider its SQL counterpart...
create table s5 (
x as integer not null
, y as integer not null
, z as integer not null
) primary key (x,y,z)
...then consider the following view
select x, y, z from s5
...my point is that the following possible output in one possible
representation of the relvar...
1, 2, 3
3, 5, 5
..considering this output is a direct disk image implementation meaning
disk storage mechanism and in-memory representation in current SQL DBMS
are *physically* storing
Adress 1/ 1, 2, 3
Adress 2/ 3, 5, 5
I do not understand why you advocate the idea that this particular
physical implementation is anything else than bidimensional? (The
relvar is not of course). I think I missed something.
Thank you for your valuable insight. Exchanging online is a difficult
exercice.
Cimode
which limits their ability to represent relvar adequately. They can
only manipulate relvar on a representation per representation basis.
<<See above, and what analogy do you have in mind ?>>Please read above.
A ruby's cube has 3 dimensions (width, length, depth). When you look
at one face of the cube you see only 2 dimensions. These 2 dimensions
are on possible representation of the cube.
Marshall
>
> Second, I make a clear distinction between SQL tables *as implemented
> currently* and relvars (called also R-tables). On that standpoint, I
> do not see how are current *physical* implementations of SQL are
> multidimensional when all the ones I know (but I only know the main
> exposed above) use direct image storage of tuple physical
> implementation.(totally defeating relational independence between
> logical and physical layer).
Okay; you're discussing the physical layer here. (Although your
parenthetical remark is incorrect; the choice of a particular
implementation strategy isn't what determines whether
you have independence or not.)
> So I am curious to why, presicely you are
> saying that a SQL table is multidimensional.
Whoops! Now you're talking about the logical layer.
As Bob already said, a relation with N attributes is n-dimensional.
This is true regardless of whether you implement that relation
with a row store or a column store or a piggy bank of slips
of paper. This is by definition.
> My guess is that you are
> refering to what SQL should be as opposed as to how it is implemented.
> On that case, I agree with that statement. On the opposite case
Not really; the reference is to the logical layer rather than the
physical layer. There's no "should be" here; that's how it is.
> Third, the hidden agenda of this thread is to focus discussion on
> in-memory logic projection of relvars assuming total independence
> between disk based storage and representation of R-Tables at runtime.
> As you also know current SQL implementations (and SQL implemented
> tables) are direct projection of physically static (generally
> bidimensional) representation of tuples.
No, I don't think that's correct at all. Physical memory is
unidimensional;
everything else is a layer on top of that.
> On such perspective, the
> little education I have about OO mechanisms encourages me to seek
> discussion with OO audience to educate myself about possibilities OO
> can offer to drive a better relational implementation.
Well, I wouldn't do that if I were you. I think your best bet is to
study the existing literature on relational implementation.
Read ten papers and see if you think OO has something
useful to say.
Marshall
Cimode
parenthetical remark is incorrect; the choice of a particular
implementation strategy isn't what determines whether
you have independence or not.)>>
You consider relvar and R-Table physical layer? Can't agree with that
(must have missed something). Only SQL implementation (storage,
operation) are physical layer. Also, while you can logically
*conclude* that you do or do not have data independence for a
particular physical implementation puts emphasis on implementation
layer to satisfy requirements for data independence.
<< No, I don't think that's correct at all. Physical memory is
unidimensional;>>
Please explain your point.
<< Well, I wouldn't do that if I were you. I think your best bet is to
study the existing literature on relational implementation.
Read ten papers and see if you think OO has something
useful to say.>> Thanks for the word of caution.(I appreciate) but I
already started doing that. Diversifying sources helps too. ;)
Marshall
> <<Okay; you're discussing the physical layer here. (Although your
> parenthetical remark is incorrect; the choice of a particular
> implementation strategy isn't what determines whether
> you have independence or not.)>>
>
> You consider relvar and R-Table physical layer? Can't agree with that
> (must have missed something).
When you snip as much as you do, it is harder for me to
have a dialog. You talked about physical concerns, which
I pointed out, and now you say you weren't discussing
physical concerns, but you've snipped the paragraph
I was responding to, which discussed implementation
and physical concerns.
I'll try to be very clear:
In the RM, and in SQL, the logical model is what it is:
multidimensional. This is true regardless of the
physical implementation.
It might be easier if you picked one level, physical or
logical, and stuck to discussing that. When you
switch back and forth so quickly, our communication
seems to break down.
> << No, I don't think that's correct at all. Physical memory is
> unidimensional;>>
> Please explain your point.
You keep saying that physical representation is two
dimensional. But that's not correct. Physical memory
is one dimensional; it is a single line of memory from
address 0 to address n.
If by "bidimensional" you mean that SQL is always
implemented as a simple row store, this is not correct.
There are products that are column stores. There are
other hybrid approaches. It is not so simple.
Bob Badour
> <<I am not certain I agree with that last sentence.>>Can you ellaborate
> on that? What
> do you have in mind?
I already elaborated. You simply omitted it from your excerpt.
> <<That's a different issue.>>You really think so? I would argue that
> it is too closely related to to be ignored.
Since you removed all context of what I wrote, I no longer have any idea
what we are discussing.
> <<However, that does not change the degree of a table and
> does not change the fact that the degree is a direct measure of the
> dimensions.>> Yes. So. I have never denied that. This is why I
> made a distinction between SQL tables as they are implemented and SQL
> tables as they should be represented.
Which is irrelevant, as I already explained.
> <<Regardless of implementation, a sphere of radius 5 has three
> dimensions
> as does the set of integral points on a sphere of radius 5. The table
> s5
> above has degree three and three dimensions: x, y and z.>>
> Yes. That's not the point.
If you are trying to make a different point, I suggest you use words
that mean something else, then.
> <<As a matter of fact, I do not know that because it is in fact not
> true.>>
> I don't understand this statement. How can you not know something and
> disqualify it as not being true. Could you ellaborate?
How can you know something when it is false? "As you well know, the sky
beneath my feet is yellow." Did you know the sky is beneath my feet? Did
you know it was yellow? Is the sky beneath my feet yellow?
> <<I think you will find far more fertile ground elsewhere.>>Probably.
> Looking at the spirit of most comments I have read in other threads NG,
> it seems collaboration is not the main overall drive in this NG. Thank
> you for pointing it out.
I think you will find collaboration here. But the collaborators are not
in the habit of holding onto nonsensical statements.
The infertile ground I referred to is OO not the newsgroup.
> << When you write that an SQL table of degree 3 has two dimensions,
> then
> what you write is nonsense regardless of your belief.>>
>
> I have not written that anywhere (have not used degree). I am curious
> however as to *what* exactly makes you believe that I said that.
I never accused you of misusing "degree". You used "dimensions"
nonsensically.
> If you don't mind, I will use your example to clarify:
>
> ...Consider the following relvar
>
> T5: x,y,z
>
> ...then consider its SQL counterpart...
>
> create table s5 (
> x as integer not null
> , y as integer not null
> , z as integer not null
> ) primary key (x,y,z)
>
> ...then consider the following view
>
> select x, y, z from s5
>
> ...my point is that the following possible output in one possible
> representation of the relvar...
>
> 1, 2, 3
> 3, 5, 5
Since neither (1,2,3) nor (3,5,5) are points on a sphere of radius 5, I
highly doubt that they will ever appear in any possible representation
of the relvar.
> ..considering this output is a direct disk image implementation meaning
> disk storage mechanism and in-memory representation in current SQL DBMS
> are *physically* storing
You have not established that at all.
> Adress 1/ 1, 2, 3
> Adress 2/ 3, 5, 5
Again, this is not necessarily the case--not even for SQL as currently
implemented by most vendors.
> I do not understand why you advocate the idea that this particular
> physical implementation is anything else than bidimensional?
Why would I think a linear address space has more than one dimension?
Why would you think the linearity of the address space says anything
about the dimensionality of an SQL table?
Cimode
have a dialog.>>
accustomed to exchanges and jargons through NG.
I do not know what *snipping* exactly means. I have however been very
clear into clarifying my position whether on a logical and physical
layer. The fact of simultaneously considering both into argumentation
does not mean I confuse them as you tend to imply.
<< In the RM, and in SQL, the logical model is what it is:
multidimensional. This is true regardless of the
physical implementation.>>
I understand now the source of confusion in communication. I have made
clear that I wished this thread would be about implementation but
refering to logical requirements seems to be confusing.
I have never denied that RM or SQL are multidimensional. I just do not
believe that current implementation of SQL are. And I have not heard
any valid argument proving the opposite.
<< It might be easier if you picked one level, physical or
logical, and stuck to discussing that. When you
switch back and forth so quickly, our communication
seems to break down.>>
Thank you for this advice. I understand its wisdom. I will try to be
more cautious.
<< You keep saying that physical representation is two
dimensional. But that's not correct. Physical memory
is one dimensional; it is a single line of memory from
address 0 to address n.>>
You are wrong. Most RAM components are two and three dimensional.
(adress, columns and sometime blocks for 64 Kbit architecture)
<< If by "bidimensional" you mean that SQL is always
implemented as a simple row store, this is not correct.
There are products that are column stores. There are
other hybrid approaches. It is not so simple.>>
No by bidimensional I mean bidimensional in their adressing scheme (row
vs columns). The only difference between simple row tore and column
store is that they switch dimensions. Their adressing scheme remains
logically bidimensional.
Which SQL DBMS products do you refer as being hybrid? column stored and
simple row store?
I suggest you check the following link from a friend of mine (Harry
McKame) who participated in the initial implementation of System R. He
has developed his own version of SQL because he understood the original
limitations of current implementations.
http://www.armadillo.fr/english/whitepapers/WHITEPAPER_2004.htm
Thank you for your insight.
mAsterdam
> Marshall wrote:
>> When you snip as much as you do, it is harder for me to
>> have a dialog.
> Communication through forums is not easy I convene. I am not
> accustomed to exchanges and jargons through NG.
>
> I do not know what *snipping* exactly means.
[snip]
In the above, I repaired some effects of your unusual
snipping and quoting style.
Maybe this helps:
http://jargon.watson-net.com/jargon.asp?w=deletia
and this:
http://www.xs4all.nl/~wijnands/nnq/nquote.html
If/when you try it, you will see it does take
some effort and some time to get used to,
but it makes sense.
vc
Cimode wrote:
> <<What's the substantial difference with repect to 'dimensionality' ?>>
> Mainly that SQL current implementation are direct image implementation
> which limits their ability to represent relvar adequately.
Hold on right there. No one is talking about implementation, much
less about 'direct image implementation', whatever it is. Please
state clearly what the difference is between two expressions describing
the variable that can contain a three dimensional object (except minor
syntactical pecularities).
>They can
> only manipulate relvar on a representation per representation basis.
>
What's that supposed to mean ?
> <<See above, and what analogy do you have in mind ?>>Please read above.
> A ruby's cube has 3 dimensions (width, length, depth).
So do both the relval and the SQL object descriptions. It's, like, a
trivial observation.
> When you look
> at one face of the cube you see only 2 dimensions. These 2 dimensions
> are on possible representation of the cube.
That does not make any obvious sense.
>
J M Davitt
> <<I am not certain I agree with that last sentence.>>Can you ellaborate
> on that? What
> do you have in mind?
>
> <<That's a different issue.>>You really think so? I would argue that
> it is too closely related to to be ignored.
>
> <<However, that does not change the degree of a table and
> does not change the fact that the degree is a direct measure of the
> dimensions.>> Yes. So. I have never denied that. This is why I
> made a distinction between SQL tables as they are implemented and SQL
> tables as they should be represented. Do you have any idea onto how an
> in memory SQL table footprint looks like on current SQL DBMS?
Clarification please: are you saying that direct image implementations
are two dimensional because all the columns are adjacent to each other
in a row? (If so, you're writing a very different language than the
readers of your posts are reading.)
[snip]
J M Davitt
> << When you snip as much as you do, it is harder for me to
> have a dialog.>>
> Communication through forums is not easy I convene. I am not
> accustomed to exchanges and jargons through NG.
>
> I do not know what *snipping* exactly means. I have however been very
> clear into clarifying my position whether on a logical and physical
> layer. The fact of simultaneously considering both into argumentation
> does not mean I confuse them as you tend to imply.
Sniping too much: eliding too much of what others wrote when
responding to their posts. Context is lost, confusion results.
By the way: what ever quoting style that is, it is hard to read.
[snip]
Cimode
have widely or deeply penetrated the market, SQL based systems are the
best we have. There may or may not be better alternatives that are
relatively unknown. >> I will take that as ellaboration. No
disagreement here.
<< Since you removed all context of what I wrote, I no longer have any
idea
what we are discussing.>>
Sorry I am not used to exchange on NG. Do not have the habits and
jargons ;) (Excuse the confusion it may have produced)
<<Which is irrelevant, as I already explained.>>
I reread your explanation but I am still doubtful about its relevance
to the point of this thread. The main point in this thread is to
exchange information on a physical standpoint as mainly. You are
placing yourself mainly on a logical standpoint on which I do not
believe we have a real disagreement.
<<How can you know something when it is false? "As you well know, the
sky
beneath my feet is yellow." Did you know the sky is beneath my feet?
Did
you know it was yellow? Is the sky beneath my feet yellow?>>I do not
see an relevance in this analogy.
<< I think you will find collaboration here. But the collaborators are
not
in the habit of holding onto nonsensical statements.>> I hope so.
<< Since neither (1,2,3) nor (3,5,5) are points on a sphere of radius
5, I
highly doubt that they will ever appear in any possible representation
of the relvar.>>
I am not doing geometry. I reused your example to illustrate that if a
specific SQL implementation *physical* representation of a relvar is
bidimensional (because its body is only column/row represented) then it
is clearly what defeats independence.
<<The infertile ground I referred to is OO not the newsgroup.>>OK.
misunderstood.(apologies for that)
<< I never accused you of misusing "degree". You used "dimensions"
nonsensically.>>I used *dimensions* in a mathematical sense. That
certainly does not make it nonsense.
<<You have not established that at all.>>
This is not formal theory formulation. I am trying primarily to
exchange through a difficult media/ Doing the best I can .(know that I
have been educating myself on Relational concepts based on
*translations* from DATE, PASCAL, DARWEN which does not make it easy
to exchange with English speaking audiences). I do not understand how
such simple concepts are so troublesome to you.
<<Why would I think a linear address space has more than one dimension?
>>
Why do you keep making me say what I do not say. I have never said
that. in memory are not one dimensional only.
<<Why would you think the linearity of the address space says anything
about the dimensionality of an SQL table?>>
I have not said nor implied that. I am suggesting that the
bidimensional (in a mathematical sense) aspect of a physical adressing
scheme may be one of the cause for the lack of independence between
logical and physical layer in current SQL DBMS.
Thank you for your insight.
Cimode
Cimode
less about 'direct image implementation', whatever it is. Please
state clearly what the difference is between two expressions
describing
the variable that can contain a three dimensional object (except minor
syntactical pecularities).>>
I have stated as several times in the initial question (feel free to
reread) that the main purpose of the thread would be exchange on that
matter. If you believe this subject is uninteresting then feel free
not to participate. If you do not know what a direct image
implementation is I suggest you do some reading on transrelational
model by Steve TARIN. As my time is as limited as yours, I suggest you
do some research on that before we can exchange in a fruitful manner.
Check the following link.
http://en.wikipedia.org/wiki/TransRelational_model
<<What's that supposed to mean ?>>I am suggesting that a physical
adressing scheme based only on a vertical and horizontal dimensions
(not relation dimensions but mathematical dimension) can only allow
only a bidimensional representation of a relvar at runtime.
<<That does not make any obvious sense>>I perfectly know this is not
*obvious* which is the reason I am opening a thread to exchange with
the nice fellows here. But not obvious does not make it nonsensical.
Thank your for your reply.
Cimode
responding to their posts. Context is lost, confusion results. >>Thank
you for this guidance. I tend to quote people sequentially in what
they say and respond to them. I will try to better.
Cimode
Not only and the fact that they are adjacent is not really the issue
but this description seems closer to what I mean. Thank you very much
for helping a better formulation of the issue. (I may have troubles
expressing the concept). This thread seems to be taking off after all.
What is your insight on that.? Can OO in-memory mechanisms be helpful
on that matter? Most people here seem to believe the opposite.
vc
Cimode wrote:
> << Hold on right there. No one is talking about implementation, much
> less about 'direct image implementation', whatever it is. Please
> state clearly what the difference is between two expressions
> describing
> the variable that can contain a three dimensional object (except minor
> syntactical pecularities).>>
>
> I have stated as several times in the initial question (feel free to
> reread) that the main purpose of the thread would be exchange on that
> matter. If you believe this subject is uninteresting then feel free
> not to participate.
No, that is not an answer. It's called a non sequitur. The question
was not about "the main purpose of the thread". You've stated earlier
that there is some difference between the relvar expression describing
a three-dimentional object and the SQL expression doing the same. I
asked a specific question: what is the difference between those two
expressions except minor syntactical differences? Are you unable to
answer the question clearly ? Do you refuse to do that ?
Relation 'flatness':
Are you saying that the mathematical relation is somehow 'flat' and due
to the purported 'flatness' is unable to express anything about, say,
geometrical objects like a sphere or a cube ? Since you've stated
earlier that the database relation (which is an implementation of the
respective mathematical relation with some unimportant pecularities) is
somehow 'flat', then you must admit that the modern math is unable to
cope with three dimensional geometrical objects. Do you still insist
on the database relation 'flatness' ? yes or no ? why ?
>If you do not know what a direct image
> implementation is I suggest you do some reading on transrelational
> model by Steve TARIN. As my time is as limited as yours, I suggest you
> do some research on that before we can exchange in a fruitful manner.
> Check the following link.
>
> http://en.wikipedia.org/wiki/TransRelational_model
Your suggestion does not carry much force because a) you appear to be
unable/unwilling to answer truly trivial questions. Your
refusal/inability to do so does not inspire much confidence in your
ability to discuss more complicated matters than the school algebra
notions. b) since you apparently advocate a novel data management
approach, you should be able to state briefly what advantages the new
approach has in comparison to the relational model and whether those
advantages are sufficient to make people convert to the new way of
doing thing. Given the level of the RM understanding you've exhibited
so far, the likelihood of your being able to present such comparison
in a meaningful way is very low.
So, for now let's postpone discussing the fancy stuff like the
'trans-relational model' and try to settle the issue of whether the
database relation is flat or not. OK ?
Bob Badour
>
> << If by "bidimensional" you mean that SQL is always
> implemented as a simple row store, this is not correct.
> There are products that are column stores. There are
> other hybrid approaches. It is not so simple.>>
> No by bidimensional I mean bidimensional in their adressing scheme (row
> vs columns). The only difference between simple row tore and column
> store is that they switch dimensions. Their adressing scheme remains
> logically bidimensional.
What are the two dimensions? Can you name them?
Bob Badour
Cimode, you use a style of quoting that doesn't work very well. Everyone
else uses the indented style with the list of who wrote which level of
indentation at the top with matching indentation.
You remove almost all context when you <<quote some tiny part>> without
indicating who you are quoting, what came before or what came after.
Bob Badour
> Cimode wrote:
>
>
> Your suggestion does not carry much force because a) you appear to be
> unable/unwilling to answer truly trivial questions. Your
> refusal/inability to do so does not inspire much confidence in your
> ability to discuss more complicated matters than the school algebra
> notions. b) since you apparently advocate a novel data management
> approach, you should be able to state briefly what advantages the new
> approach has in comparison to the relational model and whether those
> advantages are sufficient to make people convert to the new way of
> doing thing. Given the level of the RM understanding you've exhibited
> so far, the likelihood of your being able to present such comparison
> in a meaningful way is very low.
>
> So, for now let's postpone discussing the fancy stuff like the
> 'trans-relational model' and try to settle the issue of whether the
> database relation is flat or not. OK ?
VC, Cimode is not trying to introduce a new logical data model.
However, he seems unable to communicate sensibly in english. For
instance, he keeps referring to bidimensionality of a physical
representation of a row when that is basically meaningless to the
anglophones according to the definitions of the terms he uses, and he
has made absolutely no effort to try to define the terms he is using.
I asked him point blank why he thought the linearity of the address
space had any bearing on the dimensionality of the table, and he ignored
the question. I don't think he understands enough english to participate
effectively.
His posts are extremely wordy and nonsensical. If he had a better grasp
of the language, I think he would communicate more succinctly and make
more sense.
Instead of trying to find better (ie. accurate and succinct) vocabulary,
he just keeps repeating the nonsense.
Alvin Ryder
> I noticed a recurring commercial argumentation about creating
> *behavior* into components (named classes). This caracteristics is
> often presented as being a differentiation of relational model where no
>
> such thing really exists (and in fact is not necessary). In a word, In
>
> OO approach (for whatever it may rely on), one of the main limitation
> of relational model would be not to allow its elementary components to
> emulate elementary predefined processes (transformations for instance).
>
[I added comp.object since we're talking about bridging and OOP].
Actually the relational model (RM) allows for and expects "user defined
types", a user defined type without operators is useless so it also
expects user defined operators. Operators are also called functions or
methods and that is what OOP proponents refer to as "behavior".
Data+code.
But most commercial DBMS don't make it easy to create user (programmer)
defined attribute types. You can easily use the vendor supplied types
but defining your own is another story. However this limitation was
never imposed by the RM.
>
>
> I have the impression, there is a concept, unbearable to some
> programmers that data management systems can not be anything else than
> a mechanized set of tool that could help structuring data for human
> interpretation. On that standpoint, relational model components
> reflect an approximation of *meaning* concept as being a contextualized
>
> and specific combination of constraints, business rules to make
> predefined inferences about that data for preparing interpretation.
> Processes are defined only according to specifically defined
> inferences. On the other side, OO approach seems to advocate that some
>
> level of elementary process autonomy will end up creating *some* form
> of intelligence thanks to some cumulative effect. On such perspective,
> I start suspecting all debate stating behavior lacking in the
> relational model is an empty unfounded attempt of some IT professional
> to project their scifi fantasies about what system could do and what
> they can actually do in a realistic manner.
>
> On the other side, some OO advocates state that OO approach brings some
>
> features that would seem to better implementations of subtype and
> supertypes features through inheritance as well as a better in memory
> physical handling of non primitive types than what we are accustomed to
>
> with traditional SQL implementations.
>
> I am curious about your opinion about this matter as this is a new
> board for me. (Sorry if you have noticed some english errors as it is
> not my native language) so bear with me please.
The biggest bridge between the RM and OOP appears to be coming from
Chris Date and co.
In earlier editions of "Introduction to Databases ..." he uses the word
"atomic" and gives clear examples where a Set is *not* allowed as an
attribute (column). The set elements {A, B, C} had to be "decomposed
and normalized".
But later, in books like "Database in Depth", this definition was
"clarified" - "domains are types", now you *can* have an attribute
(column) of type Array, Set and whatever else. As long as you only have
a single value or instance of a type like Set it's OK.
For example: Set instances like {A, B, C} are allowed in a column,
other tuples (rows) might have {A, B}, {A}, {} in that same column. But
none can have {A, B, C} + {X, Y Z} because that isn't a /single/ value
or instance.
You can even have an attribute of type Relation and plug an entire
relation into an attribute (RVA). Now since we already have operators
to handle relations why not allow it to be decomposed?
I hope it can be seen this "reclarified" definition is no small step in
bridging OOP and the RM. If you use relational keys instead of in
memory pointers, in theory, you now have enough to support "object
based" programming (ie OOP with no inheritence)!
In "The Third Manifesto" we go one step further, sub-types are covered
which opens up the inheritence door as well.
In practice most people I've encountered are stuck on the earlier
"Intro to databases" definitions, they'll get a shock when they see
ADT's in SQL 3. But all SQL aside, in theory the gap between OOP and RM
is much smaller.
As Date urges in "Db in depth" "now all we need is to implement the
relational model" (paraphrased).
Cheers.
Cimode
As a proof of good faith that I am not trying to ellide your questions.
I will change the quoting. Hope this will clarify...
Bob Badour wrote:
<<What are the two dimensions? Can you name them?>>
For bidimensional RAM's, the 2 dimensions are RowAddress and
ColumnAddress
For tridimensional RAM's (64bit architectures) the 3 dimensions are
Block Adress, RowAddress, ColumnAddress
Does that make sense? It was written above.
Cimode
You declared talking about the posting I previously made
// instance, he keeps referring to bidimensionality of a physical
representation of a row when that is basically meaningless to the
anglophones according to the definitions of the terms he uses, and he
has made absolutely no effort to try to define the terms he is
using.//
At several occasions in the thread, I gave explicit (which makes them
look *wordy* according to your communication standard) explanations and
even reused you own examples to point out the fundamental issue at
stake which is in-memory representation of relvars and what kind of OO
mechanisms could help improving the situation. But you got the nerve
indicating that I make no effort to define them!
What exact form of definition may help then (please answer this
particular question)? You pointed out at several occasions that these
statement were nonsense? At least 2 people on this thread have made
sense and addressed the main issue asking relevant questions ( J M
Davitt and Alvin Ryder).
As nonsense can not be understood by anybody because it lacks
coherence, the logic behind you declaring that my comments are being
nonsense is basically flawed.
I have at several occasions pointed out that the points you made were
irrelevant to the objective of this thread but you keep bringing back
the subject off track and blaming me for being repetitive.
//I asked him point blank why he thought the linearity of the address
space had any bearing on the dimensionality of the table, and he
ignored
the question. I don't think he understands enough english to
participate
effectively.//
My grasp of english is far from being perfect (I know that) but it is
sufficient to point out that the question you adressed is irrelevant.
Answer is this last question is obviously no. How can you ask this
question when I clearly indicated that physical layer does not define
logical deifnition of an R Table. You even indicated rightfully to vc
that I am not trying to redefine a logical model. What you believe is
the question I have adressed would have indicated the opposite.
Again, my belief is the fact that physical addressing scheme (be it
linear or bidimensional) has a limiting effect onto representating and
therefore manipulating adequately a relvar which is totally different
from what you think I am stating.
I hope this makes more sense.
//His posts are extremely wordy and nonsensical. If he had a better
grasp
of the language, I think he would communicate more succinctly and make
more sense.//
I will be more succint from now on.
// Instead of trying to find better (ie. accurate and succinct)
vocabulary,
he just keeps repeating the nonsense.//
I have counted the word *nonsense* and the adjective *nonsensical* at
least 6 times in your comments and you blame me being repetitive...
While I initially believed you meant *nonsense* as a synonym to *no
making any sense* and that it was due to my lack of english
proficiency, your hastiness to disqualify anything that does not fit
your perception of what is and what is not relevant makes this term a
blackbox term in which you try to put people's comments and intentions.
Therefore, I would ask you to stop using it as it traduces a lack of
respect for the efforts I am putting into trying to exchange with you.
Cimode
Thank you for helping adress this complex issue...
//Actually the relational model (RM) allows for and expects "user
defined
types", a user defined type without operators is useless so it also
expects user defined operators. Operators are also called functions or
methods and that is what OOP proponents refer to as "behavior".//
I am not convinced functions and methods are sufficient to adress the
RM issue of RTabme representation and manipulation. Operators are just
a part of what a data type is. My understanding is that *behavior*
(through methods and functions) may address the issue of manipulation
but not sufficiently the issue of adequate representation of relvar.
SQL table on the other hand address the representation in a clear but
limited manner.
Data+code.
// But most commercial DBMS don't make it easy to create user
(programmer)
defined attribute types. You can easily use the vendor supplied types
but defining your own is another story. However this limitation was
never imposed by the RM.// Yes no doubt about that. Limitation comes
clearly from current implementation of SQL. My guess is that this
limitation is bound to the current in memory addressing schemes that
fail to represent and therefore to manipulate adequately relvar. What
kind
//In earlier editions of "Introduction to Databases ..." he uses the
word
"atomic" and gives clear examples where a Set is *not* allowed as an
attribute (column). The set elements {A, B, C} had to be "decomposed
and normalized.//
But later, in books like "Database in Depth", this definition was
"clarified" - "domains are types", now you *can* have an attribute
(column) of type Array, Set and whatever else. As long as you only
have
a single value or instance of a type like Set it's OK.
For example: Set instances like {A, B, C} are allowed in a column,
other tuples (rows) might have {A, B}, {A}, {} in that same column.
But
none can have {A, B, C} + {X, Y Z} because that isn't a /single/ value
or instance.
You can even have an attribute of type Relation and plug an entire
relation into an attribute (RVA). Now since we already have operators
to handle relations why not allow it to be decomposed?
I hope it can be seen this "reclarified" definition is no small step
in
bridging OOP and the RM. If you use relational keys instead of in
memory pointers, in theory, you now have enough to support "object
based" programming (ie OOP with no inheritence)!
In "The Third Manifesto" we go one step further, sub-types are covered
which opens up the inheritence door as well.
In practice most people I've encountered are stuck on the earlier
"Intro to databases" definitions, they'll get a shock when they see
ADT's in SQL 3. But all SQL aside, in theory the gap between OOP and
RM
is much smaller.//
Yes. What would be the consequences onto defining physical schemes in
memory. How should these look like to optimize decompositions and
normalization? At present time most RAM are cut out in Row/Column
Adresses and the 64 bit architectures tend to add Memory Blocks
addressing schemes. What correlations are possible into representing
RTables (logical tables)?
Alfredo Novoa
Cimode ha escrito:
> << This does not make any sense, the dimension of a relvar is the
> number
> of attributes.>>Absolutely. but SQL table implementations are not
> relvar, just a possible representation of a relvar.
This does not make any sense.
> Commonly
> implemented SQL DBMS Tables are bidimensional.
A SQL table with three attributes is always three dimensional
independently of how it is implemented. If you can not understand this
then it does not make sense to continue the discussion.
It does not make any sense to talk about the dimensionality of the
hidden internal representation.
> << The only way to do this is to force all logical tables to have two
> attributes.>>Why is that? What sources makes you believe that?
> (Curious about that assertion) Are you refering to Transrelational
> Model?
Of course not.
> <<I suppose that you know how to represent a cube with a table.>> It is
> an analogy used for communication's sake. You misread and
> misunderstood my comment. I said that a face of a cube is
> bidimensional and is a comparable to what a SQL Table is to a relvar.
Your comparation is completely nonsensical.
> <<Are you suggesting that the memory is less physical than the
> disk?>>Interesting question but the answer is obviously no.
Indeed but your previous post seems to suggest the contrary.
> The
> argument here is about getting better independence *progressively*
> through thinking as to how in-memory representation of relvar could be
> more truthful to what a relvar .
Another completely incoherent paragraph.
> The question is whether OO in-memory
> mechanisms could support such effort. And how?
The answer is evident to me: OO has nothing to offer. Both things are
completely unrelated.
Regards
Alfredo
Alfredo Novoa
Bob Badour ha escrito:
> His posts are extremely wordy and nonsensical. If he had a better grasp
> of the language, I think he would communicate more succinctly and make
> more sense.
I agree on that they are wordy and nonsensical, but I would not expect
something a lot more coherent with a better grasp of the language.
Regards
Alfredo
Cimode
Alfredo Novoa,
Cimode ha escrito:
>
> > << This does not make any sense, the dimension of a relvar is the
> > number
> > of attributes.>>Absolutely. but SQL table implementations are not
> > relvar, just a possible representation of a relvar.
>
> This does not make any sense.
It does not make any sense because you are confusing R-Table/SQL table
and their punctual in-memory representation at runtime.
//A SQL table with three attributes is always three dimensional
independently of how it is implemented.//
At logical level yes but not at physical level.
You advance a strong argument without anything to back it up Prove it.
What is the in-memory representation of a SQL table at run time?
// If you can not understand this
then it does not make sense to continue the discussion.//
If you can not understand the difference between a relvar and what can
be its physical representation then you are probably are right that
there is no point you bringing additional confusing comments to this
thread that has a clearly defined scope (not logical, spell with me
P-H-Y-S-I-C-A-L). Several people have already understood the issue
here but you are not one of them.
//<<I suppose that you know how to represent a cube with a table.>> It
is
an analogy used for communication's sake. You misread and
misunderstood my comment. I said that a face of a cube is
bidimensional and is a comparable to what a SQL Table is to a relvar.
//Your comparation is completely nonsensical.// This is getting
boring.
Are you suggesting that the memory is less physical than the
> > disk?>>Interesting question but the answer is obviously no.
>
> Indeed but your previous post seems to suggest the contrary.
>
The
argument here is about getting better independence *progressively*
through thinking as to how in-memory representation of relvar could be
more truthful to what a relvar .
//Another completely incoherent paragraph.//
This is getting repetitive but I should clarify that...Do you deny that
the body of a relvar represented after a select x, y, z is ran is
anything else similar to
X-AXIS----------------
Y-AXIS 1,2,3
- 2,4,4
- 4,4,4
- 5,5,8
Do you deny that X and Y represent mathematical dimensions?
Do you support that the above representation is the relvar itself. If
you answered yes to any of the above questions then you are wrong dead
wrong.
// The answer is evident to me: OO has nothing to offer. Both things
are
completely unrelated.//
Prove it. If your knowledge of OO mechanisms is as effective as the
confusions you are making between logical and physical layers, I doubt
you have any credibility onto convincing me of that.
Cimode
Alfredo Novoa,
//His posts are extremely wordy and nonsensical. If he had a better
grasp of the language, I think he would communicate more succinctly and
make
more sense.//
I agree on that they are wordy and nonsensical, but I would not expect
something a lot more coherent with a better grasp of the language.//
On that I won't argue, as my communication is not as efficient as I
would like it to be
Bob Badour
It doesn't make sense yet. First, you will have to define: "RowAddress",
"ColumnAddress" and "BlockAddress" as part of some coherent
computational model.
Obviously, you are trying to define some computational model for the
physical implementation of a dbms. You apparently want to discard the
linear memory addressing scheme used on almost all computer
architectures for a different addressing scheme.
Once you completely define the computational model, what you say might
make sense. Until then, you are just using meaningless terms.
Apparently, in your addressing scheme, one may not access memory through
a single pointer. Instead, one must use three pointers.
JXStern
<bba...@pei.sympatico.ca> wrote:
>Apparently, in your addressing scheme, one may not access memory through
>a single pointer. Instead, one must use three pointers.
I just wandered (back) into the newsgroup yesterday for the first time
in a while, and onto this thread in the middle of things, and have
only read a few exchanges, but maybe this is the crux of Cimode's
concerns about memory yada yada.
Odd that this thread doesn't seem to use terms like "projection" or
"composition" (maybe I did see "decomposition"). Or, y'know,
"semantics".
The relational model really only uses one "relation", which is
adjacency. Perhaps this is another Cimode concept in the making. You
can have as many dimensions of adjacency as you like. You can
reinterpret a dimension of adjacency as something else, like time
sequence, but as soon as you do, you run across the limits of the
relational model. Now, it is also the great strength of the
relational model that it is built so simply, and the question is
whether that strength is comprimised when we go to extend it.
I continue to be nonplussed by recent Date advocacies of sets as field
domains. OTOH, I am also nonplussed by the industry's history of
limiting user defined types and corresponding operators along the
model of C++. Sure, you can make a mess (see any large C++ program
for proof!), but that is the only technical direction from the limits
of the current "flat" (adjacency) relational model to the fancy, rich
New World we all want to get to.
J.
Bob Badour
> Bob Badour,
>
> You declared talking about the posting I previously made
>
> // instance, he keeps referring to bidimensionality of a physical
> representation of a row when that is basically meaningless to the
> anglophones according to the definitions of the terms he uses, and he
> has made absolutely no effort to try to define the terms he is
> using.//
>
> At several occasions in the thread, I gave explicit (which makes them
> look *wordy* according to your communication standard) explanations and
> even reused you own examples to point out the fundamental issue at
> stake which is in-memory representation of relvars and what kind of OO
> mechanisms could help improving the situation. But you got the nerve
> indicating that I make no effort to define them!
With all due respect, your use of "bidimensionality" is nonsense. You
claim to use it to refer to the physical level of discourse but then you
use it when referring directly to logical entities.
You claim that physical memories are multidimensional; however, on the
one occasion I recall anyone using a computational model with multiple
dimensions of memories, it was used in the constructive proof that a
single-tape turing machine is just as expressive as a multiple-tape
turing machine.
Segmented memory is not the same as two-dimensional memory.
Virtual memory is not the same as two-dimensional memory.
Paged memory is not the same as two-dimensional memory.
In the computational models people will find familiar, memory uses a
linear address space: it has one dimension generally expressed as an
unsigned integer defined in some large range. That property is a
property of the physical address space and not a property of the data
stored in the memory.
If you plan to use an unfamiliar computational model, you will have to
fully define that computational model or nobody will have a clue what
you are talking about.
To give yourself some indication of why anglophones cannot understand
you when you use the word "bidimensionality" while flitting between the
logical and the physical, I suggest you search for the following terms
on google including the quotation marks for each.
"virtual memory"
"segmented memory"
"linear memory"
"bidimensional memory"
While I get tens of thousands of hits or more for the first two, I get a
total of 4 hits for the last one. Two of those hits relate to
psychology. One of those hits defines a computational model for the
study of evolution. The remaining hit, which is only available in the
cache, appears in the description of a speech given once about a year
ago on a topic of digital image processing related to cryptography.
> What exact form of definition may help then (please answer this
> particular question)?
If you want to use a computational model using a non-linear address
space, you will have to fully define the computational model.
You pointed out at several occasions that these
> statement were nonsense?
For good reason. The statements made absolutely no sense even after you
tried to clarify them.
At least 2 people on this thread have made
> sense and addressed the main issue asking relevant questions ( J M
> Davitt and Alvin Ryder).
J M Davitt asked once for clarification indicating you were not
communicating well and once pointed out that your style of quoting
interferes with communication. I don't recall him expressing any
confidence in his comprehension of what you wrote.
I long ago added Alvin to my twit-filter. I forget whether that was due
to a lack of intellectual honesty on his part or worse. That he might
pretend to make sense of what you wrote does not make it any more sensible.
> As nonsense can not be understood by anybody because it lacks
> coherence, the logic behind you declaring that my comments are being
> nonsense is basically flawed.
You have not established that anyone really made sense of what you
wrote. One person tried to rephrase what you wrote into something he
considered sensible, and he asked you for clarification at that time.
The other person is just a fool. Fools talk nonsense all the time.
> I have at several occasions pointed out that the points you made were
> irrelevant to the objective of this thread but you keep bringing back
> the subject off track and blaming me for being repetitive.
Nothing is really relevant to nonsense. I am trying to give you an
opportunity to rephrase what you are trying to communicate into
something sensible. You keep refusing and insisting that your prior
gibberish should make sense to people. Clearly, it does not.
> //I asked him point blank why he thought the linearity of the address
> space had any bearing on the dimensionality of the table, and he
> ignored
> the question. I don't think he understands enough english to
> participate
> effectively.//
> My grasp of english is far from being perfect (I know that) but it is
> sufficient to point out that the question you adressed is irrelevant.
I disagree. Confusing a property of a physical address space with a
property of a logical entity is nonsense. When I put a potato into
boiling water, I don't conclude that the boiling point of potatos is 100
degrees celsius nor do I conclude it is a property of cooked potatos as
opposed to potatos in general.
Yet, having put a logical structure into a linear memory, you expressed
a property of the linear memory as a property of the logical structure.
Don't do that. It's nonsense even if you say it only applies to the
implementation of the logical structure in the physical address space.
> Answer is this last question is obviously no. How can you ask this
> question when I clearly indicated that physical layer does not define
> logical deifnition of an R Table.
You and I obviously use different definitions for "clearly". You clearly
and repeatedly used "bidimensionality" in reference to an SQL table.
You even indicated rightfully to vc
> that I am not trying to redefine a logical model.
I simply repeated your claim, and I am trying to give you the benefit of
the doubt. Thus far, I have assumed the problems with communication
stemmed from your use of a foreign language, and I am trying to give you
the opportunity to overcome that impediment.
What you believe is
> the question I have adressed would have indicated the opposite.
It wasn't a yes or no question. You seem to be claiming that I asked a
loaded question; however, I think most of the knowledgeable english
speaking people will find the question very reasonable given your
previous statements.
Are you saying you want to rephrase what you wrote previously such that
you no longer express the properties of the physical memory as
properties of the logical entity?
> Again, my belief is the fact that physical addressing scheme (be it
> linear or bidimensional) has a limiting effect onto representating and
> therefore manipulating adequately a relvar which is totally different
> from what you think I am stating.
>
> I hope this makes more sense.
I am not sure why you think that. I suggest you consider:
http://en.wikipedia.org/wiki/Turing_machine#Multi-tape_machines
I likewise suggest you consider that the various classes of automata can
accept the same languages:
http://en.wikipedia.org/wiki/Automata_theory#Classes_of_automata
> //His posts are extremely wordy and nonsensical. If he had a better
> grasp
> of the language, I think he would communicate more succinctly and make
>
> more sense.//
>
> I will be more succint from now on.
>
> // Instead of trying to find better (ie. accurate and succinct)
> vocabulary,
> he just keeps repeating the nonsense.//
> I have counted the word *nonsense* and the adjective *nonsensical* at
> least 6 times in your comments and you blame me being repetitive...
>
> While I initially believed you meant *nonsense* as a synonym to *no
> making any sense* and that it was due to my lack of english
> proficiency, your hastiness to disqualify anything that does not fit
> your perception of what is and what is not relevant makes this term a
> blackbox term in which you try to put people's comments and intentions.
>
> Therefore, I would ask you to stop using it as it traduces a lack of
> respect for the efforts I am putting into trying to exchange with you.
I am not sure how else you want me to express that something you write
makes no sense. While I understand it will require much more work from
you to discover or look up the correct english word for what you are
trying to communicate, making up gibberish wastes time while defeating
your purpose.
Bob Badour
> Cimode ha escrito:
>
>> The question is whether OO in-memory
>>mechanisms could support such effort. And how?
>
> The answer is evident to me: OO has nothing to offer. Both things are
> completely unrelated.
Hear! Hear!
J M Davitt
A couple points: although many SQL implementations are direct image -
meaning that rows are stored as rows and tables are stored as tables -
not all of them are. In other words, there are implementations where
a table's rows and a row's columns are "spread out all over the place."
This has nothing to do with either the relational model or SQL.
As for "OO in-memory mechanisms," I think that such storage schemes
should be described a one-dimensional, don't you?. After all, each
instance is allocated a bunch of bits from a linear address space.
Just because it's apparently a simple matter to pass an address
around doesn't mean that the content of all addresses are easily
accessed. MIPS chips and Intel chips have very different techniques
for managing large memory fields. But that fact doesn't have anything
to do with OO concepts, does it? Well, neither does the choice of
storage technique have anything to do with relational concepts or SQL.
Bob Badour
> Alfredo Novoa,
> Cimode ha escrito:
>
>>><< This does not make any sense, the dimension of a relvar is the
>>>number
>>> of attributes.>>Absolutely. but SQL table implementations are not
>>>relvar, just a possible representation of a relvar.
>>
>>This does not make any sense.
>
> It does not make any sense because you are confusing R-Table/SQL table
> and their punctual in-memory representation at runtime.
>
> //A SQL table with three attributes is always three dimensional
> independently of how it is implemented.//
>
> At logical level yes but not at physical level.
At any level, Cimode. If you don't mean to refer to the SQL table, then
refer to something else that you do mean. Any triplet, though,
represents three dimensions.
Are you referring to a two-dimensional array representing the table? Are
you referring to something else?
> You advance a strong argument without anything to back it up Prove it.
> What is the in-memory representation of a SQL table at run time?
Anything one wants that represents the SQL table. It might depend on the
indexes used. It might depend on how one distributes the table. It might
never get represented exactly as a table at all.
[snip]
Several people have already understood the issue
> here but you are not one of them.
You advance a strong argument without anything to back it up. Prove it.
> //<<I suppose that you know how to represent a cube with a table.>> It
> is
> an analogy used for communication's sake. You misread and
> misunderstood my comment. I said that a face of a cube is
> bidimensional and is a comparable to what a SQL Table is to a relvar.
And any representation of a face of a cube is bidimensional. However,
any representation of the cube is three dimensional, or it no longer
represents a cube. Don't confuse the projection of a cube with a cube.
> //Your comparation is completely nonsensical.// This is getting
> boring.
>
> Are you suggesting that the memory is less physical than the
>
>>>disk?>>Interesting question but the answer is obviously no.
>>
>>Indeed but your previous post seems to suggest the contrary.
>
> The
> argument here is about getting better independence *progressively*
> through thinking as to how in-memory representation of relvar could be
> more truthful to what a relvar .
You have already stated that. However, you then immediately confused the
logical and the physical again.
Any in-memory representation of a relvar that represents a relvar is
truthful to what a relvar is. Otherwise, it doesn't represent a relvar.
Similarly, any in-memory representation of an SQL table that represents
an SQL table is truthful to what an SQL table is. Otherwise, it doesn't
represent an SQL table.
What in-memory representation do you want to discuss? A row store? A
column store? Some other representation? Others have offered you
alternative vocabulary for what they think you might mean, but you
totally ignored it every time.
> //Another completely incoherent paragraph.//
> This is getting repetitive but I should clarify that...Do you deny that
> the body of a relvar represented after a select x, y, z is ran is
> anything else similar to
>
> X-AXIS----------------
> Y-AXIS 1,2,3
> - 2,4,4
> - 4,4,4
> - 5,5,8
>
> Do you deny that X and Y represent mathematical dimensions?
But the dimensions of what? A piece of paper? A computer monitor? That
is the point that seems to elude you. Neither X nor Y are properties of
the relvar or of the implementation of the relvar.
The body of the relvar remains unaltered by the select as does the
implementation of the relvar.
> Do you support that the above representation is the relvar itself.
No, it isn't the relvar itself. It is a representation of a relation on
my computer monitor (when I look at it.) X and Y are dimensions of my
computer monitor.
If
> you answered yes to any of the above questions then you are wrong dead
> wrong.
>
> // The answer is evident to me: OO has nothing to offer. Both things
> are
> completely unrelated.//
> Prove it. If your knowledge of OO mechanisms is as effective as the
> confusions you are making between logical and physical layers,
Alfredo has shown no indication whatsoever of confusing anything. If
your only goal is to insult the people who are trying to help you, you
can go fuck yourself.
Bob Badour
> On Sun, 04 Jun 2006 17:25:04 GMT, Bob Badour
> <bba...@pei.sympatico.ca> wrote:
>
>>Apparently, in your addressing scheme, one may not access memory through
>>a single pointer. Instead, one must use three pointers.
>
> I just wandered (back) into the newsgroup yesterday for the first time
> in a while, and onto this thread in the middle of things, and have
> only read a few exchanges, but maybe this is the crux of Cimode's
> concerns about memory yada yada.
>
> Odd that this thread doesn't seem to use terms like "projection" or
> "composition" (maybe I did see "decomposition"). Or, y'know,
> "semantics".
We haven't gotten that far yet. We are still trying to make sense of
what Cimode wants.
> The relational model really only uses one "relation", which is
> adjacency.
I disagree with the term "adjacency" as it implies physical location of
some sort and necessarily refers to a physical representation of a tuple
as opposed to the tuple itself--all the while ignoring the ability to
name predicates.
[snip]
Cimode
asource of confusion.
Bob Badour wrote:
> Cimode wrote:
> > To Bob Badour
> >
> > As a proof of good faith that I am not trying to ellide your questions.
> > I will change the quoting. Hope this will clarify...
> >
> > Bob Badour wrote:
> > <<What are the two dimensions? Can you name them?>>
> > For bidimensional RAM's, the 2 dimensions are RowAddress and
> > ColumnAddress
> > For tridimensional RAM's (64bit architectures) the 3 dimensions are
> > Block Adress, RowAddress, ColumnAddress
> >
> > Does that make sense? It was written above.
>
> It doesn't make sense yet. First, you will have to define: "RowAddress",
> "ColumnAddress" and "BlockAddress" as part of some coherent
> computational model.
It does not makes *yet*?. Mister, what is nonsense does not make sense
*ever*.
Besides when was the last time you checked memory architectures? in the
80's? Current 64 bit memory architectures already support this
adressing scheme without the need to inventing a computational model
(For whatever it maybe). What do you call *linear*
>
> Obviously, you are trying to define some computational model for the
> physical implementation of a dbms. You apparently want to discard the
> linear memory addressing scheme used on almost all computer
> architectures for a different addressing scheme.
>
> Once you completely define the computational model, what you say might
> make sense. Until then, you are just using meaningless terms.
>
> Apparently, in your addressing scheme, one may not access memory through
> a single pointer. Instead, one must use three pointers.
This comment is the most Interesting you have posted so far. What is
linear to you?
Cimode
//With all due respect, your use of "bidimensionality" is nonsense. You
claim to use it to refer to the physical level of discourse but then
you
use it when referring directly to logical entities.//
Your statement is incorrect. I explained the use of bidimensionality
to state that the physical representation of a relvar (in current SQL
implementation) is necessarily bidimensional at run time. Tell me
where I have declared that it's bidimensional a logical level?
//You claim that physical memories are multidimensional; however, on
the
one occasion I recall anyone using a computational model with multiple
dimensions of memories, it was used in the constructive proof that a
single-tape turing machine is just as expressive as a multiple-tape
turing machine.//
It is not a claim it's a fact. 64 bit RAM architectures use an
adressing scheme identifying adresses through 3 coordinates
BlockAddress/ColumnAddress/RowAddress. Which makes your *recalling*
essentially irrelevant.
//Segmented memory is not the same as two-dimensional memory.
Virtual memory is not the same as two-dimensional memory.
Paged memory is not the same as two-dimensional memory.//
This is high level segmentation is irrelevant. I am speaking low
level.
// In the computational models people will find familiar, memory uses a
linear address space: it has one dimension generally expressed as an
unsigned integer defined in some large range. That property is a
property of the physical address space and not a property of the data
stored in the memory.
In the computational models people will find familiar, memory uses a
linear address space: it has one dimension generally expressed as an
unsigned integer defined in some large range. That property is a
property of the physical address space and not a property of the data
stored in the memory.
//
Speaking about computational model is irrelevant. Your comment made me
however understand where the misunderstanding comes from. You are
ignoring the relative nature of hexadecimal adress retrieval. Most
addresses are computed and are a result of a absolute direct
extraction. Current RAM use 2 or 3 coordinates to identify faster
addresses on relatively to the other. The adressing scheme is
referential for computing that has been existing since VSAM. If you
suppose Linear means monodimensional and that adresses are extracted
directly, you are wrong.
// If you plan to use an unfamiliar computational model, you will have
to
fully define that computational model or nobody will have a clue what
you are talking about.// No need to comment on that see response
above.
Wont comment on the rest no need.
// For good reason. The statements made absolutely no sense even after
you
> tried to clarify them.//
Do you understand better now?
// J M Davitt asked once for clarification indicating you were not
communicating well and once pointed out that your style of quoting
interferes with communication. I don't recall him expressing any
confidence in his comprehension of what you wrote.//
Here's to refresh your selective memory.
JMDavitt first asked a question to warn me I was not communicating
clearly enough but he adressed directly the issue I was getting at.
//Clarification please: are you saying that direct image
implementations
are two dimensional because all the columns are adjacent to each other
in a row? (If so, you're writing a very different language than the
readers of your posts are reading.) //
I responded commenting onto adjacency and asking new questions to try
to direct a more productive discussion..
//Not only and the fact that they are adjacent is not really the issue
but this description seems closer to what I mean. Thank you very much
for helping a better formulation of the issue. (I may have troubles
expressing the concept). This thread seems to be taking off after all.
What is your insight on that.? Can OO in-memory mechanisms be helpful
on that matter? Most people here seem to believe the opposite. //
JMDavitt did not explicitely express that he had a comprehension of
issues at hand he just aked the right question about a subject with
delimited scope which makes the triggering argument having sense. This
is why I told you at several occasions that you miss the point (in all
respect).
// I long ago added Alvin to my twit-filter. I forget whether that was
due
to a lack of intellectual honesty on his part or worse. That he might
pretend to make sense of what you wrote does not make it any more
sensible.//
I do not know any people accustomed to this board and I do not have any
preconceived idea about what they are or say. I just try to exchange
with sincerity and respect. Alvin or you are no exceptions. I conceive
that disagreeing with them on a specific matter as being an potential
opportunity to learn something. This process may not be as practical
as puting people on twit filter when they disagree with me but it is
rewarding. My guess is I will probably be next on your twit filter
and your next thread reference as being intellectualy dishonnest.
// You have not established that anyone really made sense of what you
wrote. One person tried to rephrase what you wrote into something he
considered sensible, and he asked you for clarification at that time.
The other person is just a fool. Fools talk nonsense all the time.//
You are trying to establish nonsense on false assumptions and if
necessary you disqualify as *foolish* or *nonsensical* anything that
does not fit your perception of right and wrong.
*Fool*, *twit filter*, *nonsense* *lack of intellectual honnesty* -->
Is that your witchhunt arsenal to defend your positions when people
disagree with you and when you can not prove they are wrong. This
attitude is scary and I do mean that in a friendly manner.
// Nothing is really relevant to nonsense. I am trying to give you an
opportunity to rephrase what you are trying to communicate into
something sensible. You keep refusing and insisting that your prior
gibberish should make sense to people. Clearly, it does not.//
Sorry about that but I can not give more clarifications than I already
did to prove my good faith.
// I disagree. Confusing a property of a physical address space with a
property of a logical entity is nonsense. When I put a potato into
boiling water, I don't conclude that the boiling point of potatos is
100
degrees celsius nor do I conclude it is a property of cooked potatos
as
opposed to potatos in general.//
I am not confusing anything you are. So you use potatoes as an analogy
to explain bidimensionality of a relvar. It is totally irrelevant as
were your previous comment.
// Yet, having put a logical structure into a linear memory, you
expressed
a property of the linear memory as a property of the logical
structure.
Don't do that. It's nonsense even if you say it only applies to the
implementation of the logical structure in the physical address
space.//
No that would be totally silly. These are conclusions you are making
I stated that the SQL *physical* implementation on *current* DBMS
systems in necessarily bidimensional at run time because of the
addressing scheme used is a limiting factor to better representation
BUT I have never stated anywhere that a relvar is bidimensional. The
latest part of the sentence is your interpretation. I suspect you
either misunderstood or you are making a confusion between a relvar and
its possible in memory representation.
I know you are trying to help but it seems to me you are
<< You and I obviously use different definitions for "clearly". You
clearly
and repeatedly used "bidimensionality" in reference to an SQL table.>>
This statement is incorrect. At several occasions, I explicitely
refered to current *physical* implementations of SQL Tables in main
commercial products I named (ORACLE, DB2, SQL Server). A SQL table can
not be logically bidimensional.
// I simply repeated your claim, and I am trying to give you the
benefit of
the doubt. Thus far, I have assumed the problems with communication
stemmed from your use of a foreign language, and I am trying to give
you
the opportunity to overcome that impediment.//
Yes and I am grateful for that. Thank you for your help.
// I am not sure how else you want me to express that something you
write
makes no sense. While I understand it will require much more work from
you to discover or look up the correct english word for what you are
trying to communicate, making up gibberish wastes time while defeating
your purpose.// That's your opinion. I will keep it in mind.
Bob Badour
> I will be more succint in future comments as wordyness seems to be
> asource of confusion.
>
> Bob Badour wrote:
>
>>Cimode wrote:
>>
>>>To Bob Badour
>>>
>>>As a proof of good faith that I am not trying to ellide your questions.
>>> I will change the quoting. Hope this will clarify...
>>>
>>>Bob Badour wrote:
>>><<What are the two dimensions? Can you name them?>>
>>>For bidimensional RAM's, the 2 dimensions are RowAddress and
>>>ColumnAddress
>>>For tridimensional RAM's (64bit architectures) the 3 dimensions are
>>>Block Adress, RowAddress, ColumnAddress
>>>
>>>Does that make sense? It was written above.
>>
>>It doesn't make sense yet. First, you will have to define: "RowAddress",
>>"ColumnAddress" and "BlockAddress" as part of some coherent
>>computational model.
>
> It does not makes *yet*?. Mister, what is nonsense does not make sense
> *ever*.
I don't recall saying that the above is nonsense. I recall saying it
cannot make sense until you define the terms "RowAddress",
"ColumnAddress" and "BlockAddress". Until that time, it is merely
meaningless.
> Besides when was the last time you checked memory architectures?
I suggest you consider the name of this newsgroup. It is not
comp.intel.architecture.64bit and it is not comp.intel.mmu.64bt
If you want to discuss a specific computational model, you will have to
provide some sensible definition of that model. Even with segmented
memory, the address space is linear. Even with virtual memory, the
address space is linear. Even with paged memory, the address space is
linear.
Are you suggesting that current memory architectures are non-segmented,
non-virtual, non-paged, non-linear architectures? Are you suggesting
that this would somehow become relevant to the theoretical computational
model?
While you initially seemed to show some promise, you are beginning to
convince me you are nothing but a crank after all.
Current 64 bit memory architectures already support this
> adressing scheme without the need to inventing a computational model
> (For whatever it maybe). What do you call *linear*
I call a 1-manifold "linear". What do you call linear? What do you call
"bidimensional" ? (Other than some imagined implementation of an SQL
table, that is.)
In a computational model, I call any addressing scheme requiring single
pointers "linear". On a CPU, I call any address bus consisting of a
fixed number of external pins representing the state of some CPU
register "linear".
>>Obviously, you are trying to define some computational model for the
>>physical implementation of a dbms. You apparently want to discard the
>>linear memory addressing scheme used on almost all computer
>>architectures for a different addressing scheme.
>>
>>Once you completely define the computational model, what you say might
>>make sense. Until then, you are just using meaningless terms.
>>
>>Apparently, in your addressing scheme, one may not access memory through
>>a single pointer. Instead, one must use three pointers.
>
> This comment is the most Interesting you have posted so far. What is
> linear to you?
See above. What is linear to you? What is bidimensional? What
computational model do you want to discuss? What property of that
computational model do you think an OO computational model might improve?
Bob Badour
> Bob Badour wrote:
> //With all due respect, your use of "bidimensionality" is nonsense. You
>
> claim to use it to refer to the physical level of discourse but then
> you
> use it when referring directly to logical entities.//
> Your statement is incorrect. I explained the use of bidimensionality
> to state that the physical representation of a relvar (in current SQL
> implementation) is necessarily bidimensional at run time.
That's not exactly what you stated earlier. Now, I simply note that you
have claimed here a necessity that is not necessary. If one of your
axioms is false, any conclusions you derive from it are meaningless.
> //You claim that physical memories are multidimensional; however, on
> the
> one occasion I recall anyone using a computational model with multiple
> dimensions of memories, it was used in the constructive proof that a
> single-tape turing machine is just as expressive as a multiple-tape
> turing machine.//
> It is not a claim it's a fact. 64 bit RAM architectures use an
> adressing scheme identifying adresses through 3 coordinates
> BlockAddress/ColumnAddress/RowAddress.
Prove it.
> //Segmented memory is not the same as two-dimensional memory.
> Virtual memory is not the same as two-dimensional memory.
> Paged memory is not the same as two-dimensional memory.//
> This is high level segmentation is irrelevant. I am speaking low
> level.
Why would you consider a level below the computational model of the CPU?
Are you interested in implementing a dbms or in implementing a memory
management unit? What relevance does OO have below the computational
model of the CPU?
> // In the computational models people will find familiar, memory uses a
>
> linear address space: it has one dimension generally expressed as an
> unsigned integer defined in some large range. That property is a
> property of the physical address space and not a property of the data
> stored in the memory.
>
> In the computational models people will find familiar, memory uses a
> linear address space: it has one dimension generally expressed as an
> unsigned integer defined in some large range. That property is a
> property of the physical address space and not a property of the data
> stored in the memory.
> //
> Speaking about computational model is irrelevant.
How is the computational model irrelevant to a discussion of physically
implementing an rdbms? One cannot implement anything without a
computational model, and your suggestion that OO has anything to offer
presumably means you think some aspect of the OO computational model
will help.
Your comment made me
> however understand where the misunderstanding comes from. You are
> ignoring the relative nature of hexadecimal adress retrieval. Most
> addresses are computed and are a result of a absolute direct
> extraction. Current RAM use 2 or 3 coordinates to identify faster
> addresses on relatively to the other. The adressing scheme is
> referential for computing that has been existing since VSAM. If you
> suppose Linear means monodimensional and that adresses are extracted
> directly, you are wrong.
Here is perhaps a clue why you seem unable to communicate sensibly: you
refer to physical storage as physical memory and you refer to the image
on a magnetic disk (DASD) as "in-memory"--assuming you mean the same
thing by VSAM as other computing professionals would mean. You also seem
to think that RAM refers to magnetic storage (DASD) given your use of
the acronym in conjunction with VSAM.
Further, you take the additional bold step of stating the obvious truth
of things that are false for both the image on disk and the image in memory.
> // If you plan to use an unfamiliar computational model, you will have
> to
> fully define that computational model or nobody will have a clue what
> you are talking about.// No need to comment on that see response
> above.
>
> Wont comment on the rest no need.
I have a better idea why you seem incapable to communicate. I don't have
much hope that you will improve any time soon, though.
> // For good reason. The statements made absolutely no sense even after
> you
>
>>tried to clarify them.//
>
> Do you understand better now?
Yes. Now that I know how you personally redefine terms to mean things
completely different from everybody else, I note that the statements you
made regarding your axioms were false. Anything you conclude from those
axioms is meaningless.
> // J M Davitt asked once for clarification indicating you were not
> communicating well and once pointed out that your style of quoting
> interferes with communication. I don't recall him expressing any
> confidence in his comprehension of what you wrote.//
> Here's to refresh your selective memory.
>
> JMDavitt first asked a question to warn me I was not communicating
> clearly enough but he adressed directly the issue I was getting at.
>
> //Clarification please: are you saying that direct image
> implementations
> are two dimensional because all the columns are adjacent to each other
> in a row? (If so, you're writing a very different language than the
> readers of your posts are reading.) //
>
> I responded commenting onto adjacency and asking new questions to try
> to direct a more productive discussion..
I saw that, and I note that J M Davitt responded to those questions much
the same as everybody else here would. Given the nature of usenet,
perhaps you had not seen that response yet when you wrote the above.
J M Davitt >>there are implementations where a table's rows and a row's
columns are "spread out all over the place." This has nothing to do with
either the relational model or SQL.<<
J M Davitt >>As for "OO in-memory mechanisms," I think that such storage
schemes should be described a one-dimensional, don't you?. After all,
each instance is allocated a bunch of bits from a linear address space.<<
In other words, he seems to agree that your basic axioms are false
assuming your axioms are as they seem to be: 1) that all SQL
implementations map tables to row stores on disk or in memory, 2) that
current computational models use something other than linear address spaces.
> //Not only and the fact that they are adjacent is not really the issue
> but this description seems closer to what I mean. Thank you very much
> for helping a better formulation of the issue. (I may have troubles
> expressing the concept). This thread seems to be taking off after all.
>
> What is your insight on that.? Can OO in-memory mechanisms be helpful
> on that matter? Most people here seem to believe the opposite. //
>
> JMDavitt did not explicitely express that he had a comprehension of
> issues at hand he just aked the right question about a subject with
> delimited scope which makes the triggering argument having sense. This
> is why I told you at several occasions that you miss the point (in all
> respect).
It's easy to miss the point when trying to decypher meaning from
gibberish. Mr. Davitt guessed and got lucky apparently. However, it
seems he agrees your basic premises are false.
> // I long ago added Alvin to my twit-filter. I forget whether that was
> due
> to a lack of intellectual honesty on his part or worse. That he might
> pretend to make sense of what you wrote does not make it any more
> sensible.//
> I do not know any people accustomed to this board and I do not have any
> preconceived idea about what they are or say. I just try to exchange
> with sincerity and respect. Alvin or you are no exceptions. I conceive
> that disagreeing with them on a specific matter as being an potential
> opportunity to learn something. This process may not be as practical
> as puting people on twit filter when they disagree with me but it is
> rewarding.
I don't put people in a twit-filter for disagreeing with me. I put them
in there for wasting my time with intellectual dishonesty and/or
assertive stupidity. While I might miss an extremely rare learning
opportunity from one of them, I find I learn a lot more by focussing my
time and effort with more fertile sources of learning opportunities.
My guess is I will probably be next on your twit filter
> and your next thread reference as being intellectualy dishonnest.
Citing VSAM, a magnetic storage (DASD) technology, to justify statements
regarding "in-memory" and RAM certainly borders on intellectual
dishonesty. However, I am still giving you the benefit of the doubt that
RAM and "in-memory" might mean entirely different things to you due to
the language barrier.
> // You have not established that anyone really made sense of what you
> wrote. One person tried to rephrase what you wrote into something he
> considered sensible, and he asked you for clarification at that time.
> The other person is just a fool. Fools talk nonsense all the time.//
> You are trying to establish nonsense on false assumptions and if
> necessary you disqualify as *foolish* or *nonsensical* anything that
> does not fit your perception of right and wrong.
Well, if it makes you feel better to believe that, be my guest.
> 1) *Fool*, 2) *twit filter*, 3) *nonsense* 4) *lack of intellectual honnesty* -->
> Is that your witchhunt arsenal to defend your positions when people
> disagree with you and when you can not prove they are wrong.
(numbering added for clarity of reference)
No. That's 1) what I call people who are deficient in judgement, sense
or understanding, 2) how I avoid wasting time on fools, 3) the name I
use for words or signs having no intelligible meaning, and 4) how I
identify people who are a waste of time.
This
> attitude is scary and I do mean that in a friendly manner.
If it were my attitude, your statement would have some relevance. As it
is... [shrug]
> // Nothing is really relevant to nonsense. I am trying to give you an
> opportunity to rephrase what you are trying to communicate into
> something sensible. You keep refusing and insisting that your prior
> gibberish should make sense to people. Clearly, it does not.//
> Sorry about that but I can not give more clarifications than I already
> did to prove my good faith.
>
> // I disagree. Confusing a property of a physical address space with a
> property of a logical entity is nonsense. When I put a potato into
> boiling water, I don't conclude that the boiling point of potatos is
> 100
> degrees celsius nor do I conclude it is a property of cooked potatos
> as
> opposed to potatos in general.//
> I am not confusing anything you are.
Perhaps not now, but certainly in your earlier posts, where I and others
noted the nonsensical nature of your statements, you were confusing
them--at least in what you wrote if not in what you intended to write.
So you use potatoes as an analogy
> to explain bidimensionality of a relvar. It is totally irrelevant as
> were your previous comment.
I disagree. I suspect others would consider the analogy relevant. If any
are still reading, perhaps one or another will voice that opinion.
> // Yet, having put a logical structure into a linear memory, you
> expressed
> a property of the linear memory as a property of the logical
> structure.
> Don't do that. It's nonsense even if you say it only applies to the
> implementation of the logical structure in the physical address
> space.//
> No that would be totally silly.
Hence the responses I and others gave when you said it.
These are conclusions you are making
> I stated that the SQL *physical* implementation on *current* DBMS
> systems in necessarily bidimensional at run time because of the
> addressing scheme used is a limiting factor to better representation
First, your assertion that the implementations are necessarily
bidimensional is false. Since that appears to be one of your axioms,
anything you conclude from it is meaningless.
Second, the computational models in OO use exactly the same kind of
linear address space.
> BUT I have never stated anywhere that a relvar is bidimensional.
I agree. You stated that an SQL table is bidimensional, which is just as
nonsensical.
The
> latest part of the sentence is your interpretation.
And the interpretation of several others here. If you string together
words that mean A in english, it hardly makes sense for you to blame
english speaking people for thinking you meant A when you in fact meant B.
I suspect you
> either misunderstood
I understood what you wrote. Apparently, you did not mean what you
wrote. Since you meant something other than what you wrote, of course, I
misunderstood what you meant. There is no magic that conveys the correct
meaning with random words.
or you are making a confusion between a relvar and
> its possible in memory representation.
Nope, I understand the difference quite well. I also understand the
difference between a relvar and its representation on disk or other
storage. Your assertions regarding in memory representations were
false--thereby adding to the confusion.
> I know you are trying to help but it seems to me you are
>
> << You and I obviously use different definitions for "clearly". You
> clearly
> and repeatedly used "bidimensionality" in reference to an SQL table.>>
> This statement is incorrect. At several occasions, I explicitely
> refered to current *physical* implementations of SQL Tables in main
> commercial products I named (ORACLE, DB2, SQL Server). A SQL table can
> not be logically bidimensional.
>
> // I simply repeated your claim, and I am trying to give you the
> benefit of
> the doubt. Thus far, I have assumed the problems with communication
> stemmed from your use of a foreign language, and I am trying to give
> you
> the opportunity to overcome that impediment.//
> Yes and I am grateful for that. Thank you for your help.
>
> // I am not sure how else you want me to express that something you
> write
> makes no sense. While I understand it will require much more work from
>
> you to discover or look up the correct english word for what you are
> trying to communicate, making up gibberish wastes time while defeating
>
> your purpose.// That's your opinion. I will keep it in mind.
Thank you.
Keith H Duggar
> Bob Badour :
> > What are the two dimensions? Can you name them?
>
> For bidimensional RAM's, the 2 dimensions are RowAddress
> and ColumnAddress For tridimensional RAM's (64bit
> architectures) the 3 dimensions are Block Adress,
> RowAddress, ColumnAddress Does that make sense? It was
> written above.
Suppose we have a 16-bit architecture with 2^16 memory
cells. How many dimensions is the memory?
Suppose we call the 16-bit tuple "address". Is the physical
memory now 1-dimensional?
Without changing the physical architechure, suppose we
mentally partition the 16 bits into two 8-bit tuples and
call one "hi_reg" and the other "lo_reg". Is the physical
memory now 2-dimensional or is it still 1-dimensional?
Suppose instead we give names to each of the 16 bits.
Something like:
0 : pinky 8 : box
1 : bit 9 : crate
2 : crumb 10 : pallet
3 : chunk 11 : container
4 : unit 12 : truck
5 : finger 13 : train
6 : bar 14 : house
7 : pack 15 : big_dog
Is the physical memory now a 16-dimensional hyper-cube?
Since the physical memory is a physical object embedded in
space-time, why isn't it always 3+1-dimensional? Or maybe
10-dimensional?
What point exactly are you trying to make Cimode? This
seems much ado about nothing, to me. What am I missing?
-- Keith --
JXStern
Ya, I thought better of that as soon as I posted it. I could defend
it, but it'd be pretty argumentative and maybe still not important, or
just plain wrong, so ... never mind!
J.
Cimode
Bob Badour wrote:
// Anything one wants that represents the SQL table. It might depend on
the
indexes used. It might depend on how one distributes the table. It
might
never get represented exactly as a table at all.//
You are wrong. Indexes represent disk organisation and what allow
consitution of execution showplan and calculation to isolate data in
RAM. IO representation is a result of loading data pages(index + data)
on RAM and executing specific showplan on theses indexes as well.
Results of execution traduced as SQL tables are stored according to
simple RowAddress/ColumnAdress bidimensional scheme. How in the hell at
that moment (just before display) can they be anything else than
bidimensional according to their according coordinates on
RowAddress/ColumnAddress.
// What in-memory representation do you want to discuss? A row store? A
column store? Some other representation? Others have offered you
alternative vocabulary for what they think you might mean, but you
totally ignored it every time.//
I did not this terminology for the simple reason that I don't know what
it refers to precisely. I will check it to see if it corresponds to
what I am refering to. I missed this comment.
//> > //Another completely incoherent paragraph.//
> > This is getting repetitive but I should clarify that...Do you deny that
> > the body of a relvar represented after a select x, y, z is ran is
> > anything else similar to
> >
> > X-AXIS----------------
> > Y-AXIS 1,2,3
> > - 2,4,4
> > - 4,4,4
> > - 5,5,8
> >
> > Do you deny that X and Y represent mathematical dimensions?
>
> But the dimensions of what? A piece of paper? A computer monitor? That
> is the point that seems to elude you. Neither X nor Y are properties of
> the relvar or of the implementation of the relvar.
//
The media has nothing to do with physical addressing scheme. A
dimension according to the physical adressing scheme used in memory to
represent the result of the query. I perfectly know that this precise
X and Y have nothing to do with the dimension of a relvar which is at
logical level definition of RM. You keep switching back to logical
layer while I told a hundred times that there is no point discussing
logical level. Why do you keep putting in doubt logical definition of
relvars.
// Alfredo has shown no indication whatsoever of confusing anything. If
your only goal is to insult the people who are trying to help you//
This is BS. Prove it. I have not insulted Alfredo or anybody on this
board. If you feel insulted because I pointed out that some of your
comments were totally irrelevant or wrong because they were is not an
insult.
//, you
can go fuck yourself.//
Bob you are going too far. If this is the way you *help* people on
boards? This kind of declaration are totally contradicting what you
present as noble intentions and supposed to be meaningful. I did
tolerate until now your confusions and I will not tolerate to be
insulted and simply ignore this kind of post. You should be ashamed of
yourself.
Cimode
Bob Badour wrote:,
//> Cimode wrote:
>
> > I will be more succint in future comments as wordyness seems to be
> > asource of confusion.
> >
> > Bob Badour wrote:
> >
> >>Cimode wrote:
> >>
> >>>To Bob Badour
> >>>
> >>>As a proof of good faith that I am not trying to ellide your questions.
> >>> I will change the quoting. Hope this will clarify...
> >>>
> >>>Bob Badour wrote:
> >>><<What are the two dimensions? Can you name them?>>
> >>>For bidimensional RAM's, the 2 dimensions are RowAddress and
> >>>ColumnAddress
> >>>For tridimensional RAM's (64bit architectures) the 3 dimensions are
> >>>Block Adress, RowAddress, ColumnAddress
> >>>
> >>>Does that make sense? It was written above.
> >>
> >>It doesn't make sense yet. First, you will have to define: "RowAddress",
> >>"ColumnAddress" and "BlockAddress" as part of some coherent
> >>computational model.
> >
> > It does not makes *yet*?. Mister, what is nonsense does not make sense
> > *ever*.
>
> I don't recall saying that the above is nonsense. I recall saying it
> cannot make sense until you define the terms "RowAddress",
> "ColumnAddress" and "BlockAddress". Until that time, it is merely
> meaningless.//
Well in substance, you are saying it is nonsense until it would be
defined. This is totally incoherent.
RowAddress, ColumnAddress and BlockAddress are explicitely defined
through terminology and do not need a definition.
>
> > Besides when was the last time you checked memory architectures?
>
//I suggest you consider the name of this newsgroup. It is not
comp.intel.architecture.64bit and it is not comp.intel.mmu.64bt//
You have totally ellided that question.
The name of this newsgroup is comp.databases.theory and it is a ground
for discussing all theory related to databases including implementation
theory.
>
> If you want to discuss a specific computational model, you will have to
> provide some sensible definition of that model. Even with segmented
> memory, the address space is linear. Even with virtual memory, the
> address space is linear. Even with paged memory, the address space is
> linear.
You keep bringing computational model again. You see models
everywhere. While I told you that segmented memory has nothing to do
with physical addressing scheme for relative position of data.
>
> Are you suggesting that current memory architectures are non-segmented,
> non-virtual, non-paged, non-linear architectures? Are you suggesting
> that this would somehow become relevant to the theoretical computational
> model?
I suggested that this high level not low level.
>
> While you initially seemed to show some promise, you are beginning to
> convince me you are nothing but a crank after all.
I do not need your paternalistic to educate myself. I know how to read
and that's amply sufficient. And given theamount of incoherence you
demonstrated so far, I will take that as a compliment.
> Current 64 bit memory architectures already support this
> > adressing scheme without the need to inventing a computational model
> > (For whatever it maybe). What do you call *linear*
>
> I call a 1-manifold "linear". What do you call linear? What do you call
> "bidimensional" ? (Other than some imagined implementation of an SQL
> table, that is.)
>
> In a computational model, I call any addressing scheme requiring single
> pointers "linear". On a CPU, I call any address bus consisting of a
> fixed number of external pins representing the state of some CPU
> register "linear".
This is what I assumed. Your are confusing an absolute addressing
scheme a relative adressing scheme. You assume that all adresses in
memory are directly refered through their absolute memory only. Why do
you bring CPU into this?
> >>Obviously, you are trying to define some computational model for the
> >>physical implementation of a dbms. You apparently want to discard the
> >>linear memory addressing scheme used on almost all computer
> >>architectures for a different addressing scheme.
> >>
> >>Once you completely define the computational model, what you say might
> >>make sense. Until then, you are just using meaningless terms.
> >>
> >>Apparently, in your addressing scheme, one may not access memory through
> >>a single pointer. Instead, one must use three pointers.
> >
> > This comment is the most Interesting you have posted so far. What is
> > linear to you?
>
> See above. What is linear to you? What is bidimensional? What
> computational model do you want to discuss? What property of that
> computational model do you think an OO computational model might improve?
If I am not mistaken what you call "Linear" adressing scheme is what I
call "absolute" adressing scheme. I have not refered to a
computational model, you did. My hope is that OO *some* logical and
physical mechanisms such as a more coherent use of pointers would allow
totally dissociate physical layer from logical layer. IN the same
spirit, inheritance being distinctive of OO may allow more efficient
and coherent use subtypes/supertypes. As some posters evoked, tons of
works by serious audiences have been addressing that issue (Oh yeah you
are going to start saying that DATE is a crank).
Cimode
Bob Badour wrote:
> Cimode wrote:
>
> > Bob Badour wrote:
> > //With all due respect, your use of "bidimensionality" is nonsense. You
> >
> > claim to use it to refer to the physical level of discourse but then
> > you
> > use it when referring directly to logical entities.//
> > Your statement is incorrect. I explained the use of bidimensionality
> > to state that the physical representation of a relvar (in current SQL
> > implementation) is necessarily bidimensional at run time.
>
> That's not exactly what you stated earlier. Now, I simply note that you
> have claimed here a necessity that is not necessary. If one of your
> axioms is false, any conclusions you derive from it are meaningless.
always made crystal clear that logical was not to be redefined and that
your comment on such subjetc were irrelevant and off topic (not
convinced? prove me wrong by showing where I wrote that logical relvar
is not multidimensional). As soon as the adressed the right issues, I
have not hesitated to point it out as well.
> > //You claim that physical memories are multidimensional; however, on
> > the
> > one occasion I recall anyone using a computational model with multiple
> > dimensions of memories, it was used in the constructive proof that a
> > single-tape turing machine is just as expressive as a multiple-tape
> > turing machine.//
> > It is not a claim it's a fact. 64 bit RAM architectures use an
> > adressing scheme identifying adresses through 3 coordinates
> > BlockAddress/ColumnAddress/RowAddress.
>
> Prove it.
Check DRAM and SDRAM paper about RAM architectures
"A Basic
Overview of Commonly Encountered
types of Random Access Memory" By:Peter Haugen Ian Myers Bret Sadler
John Whidden"
http://www.rose-hulman.edu/Class/ee/yoder/ece332/Papers/RAM%20Technologies.pdf
Bidimensional adressing scheme are clearly based on
ColumnAdress/RowAdress computations of absolute adresses.
>
>
> > //Segmented memory is not the same as two-dimensional memory.
> > Virtual memory is not the same as two-dimensional memory.
> > Paged memory is not the same as two-dimensional memory.//
> > This is high level segmentation is irrelevant. I am speaking low
> > level.
>
> Why would you consider a level below the computational model of the CPU?
> Are you interested in implementing a dbms or in implementing a memory
> management unit? What relevance does OO have below the computational
> model of the CPU?
I have not made any direct link between CPU and memory adressing
scheme. I consider that the segmentation you are making is only a
consequence of a specific addressing scheme.
>
>
> > // In the computational models people will find familiar, memory uses a
> >
> > linear address space: it has one dimension generally expressed as an
> > unsigned integer defined in some large range. That property is a
> > property of the physical address space and not a property of the data
> > stored in the memory.
This is obvious. So?
> >
> > In the computational models people will find familiar, memory uses a
> > linear address space: it has one dimension generally expressed as an
> > unsigned integer defined in some large range. That property is a
> > property of the physical address space and not a property of the data
> > stored in the memory.
> > //
Why again do you speak of computational model?
> > Speaking about computational model is irrelevant.
>
> How is the computational model irrelevant to a discussion of physically
> implementing an rdbms? One cannot implement anything without a
> computational model, and your suggestion that OO has anything to offer
> presumably means you think some aspect of the OO computational model
> will help.
I do not have any certitudes about what OO can bring and whether it can
or can not bring something. The purpose of this thread is to allow RM
people and OO people to bring some insight about such subject. OTOH,
why are you convinced OO can not bring anything. Are you saying that
DATE has been making pointless assertions in hios books about what OO
may bring.
> Your comment made me
> > however understand where the misunderstanding comes from. You are
> > ignoring the relative nature of hexadecimal adress retrieval. Most
> > addresses are computed and are a result of a absolute direct
> > extraction. Current RAM use 2 or 3 coordinates to identify faster
> > addresses on relatively to the other. The adressing scheme is
> > referential for computing that has been existing since VSAM. If you
> > suppose Linear means monodimensional and that adresses are extracted
> > directly, you are wrong.
>
> Here is perhaps a clue why you seem unable to communicate sensibly: you
> refer to physical storage as physical memory
And it took you a book of explanations to understand that I was talking
purely physical.
and you refer to the image
> on a magnetic disk (DASD) as "in-memory"--assuming you mean the same
> thing by VSAM as other computing professionals would mean. You also seem
> to think that RAM refers to magnetic storage (DASD) given your use of
> the acronym in conjunction with VSAM.
Again the media (be it magnetic, screen or whatever) is irrelevant to
the discussion as I am adressing specifically and precisally the
adressing scheme implemented in physical memory to compute relative
adresses.
> Further, you take the additional bold step of stating the obvious truth
> of things that are false for both the image on disk and the image in memory.
It has nothing bold and exceptional to understand such a simple idea.
I just do not get why it seems so unobvious to you.
> > // If you plan to use an unfamiliar computational model, you will have
> > to
> > fully define that computational model or nobody will have a clue what
> > you are talking about.// No need to comment on that see response
> > above.
> >
> > Wont comment on the rest no need.
>
> I have a better idea why you seem incapable to communicate. I don't have
> much hope that you will improve any time soon, though.
State your ideas clearly. Again in your mouth this really sounds like
a compliment.
> > // For good reason. The statements made absolutely no sense even after
> > you
> >
> >>tried to clarify them.//
> >
> > Do you understand better now?
>
> Yes. Now that I know how you personally redefine terms to mean things
> completely different from everybody else, I note that the statements you
> made regarding your axioms were false. Anything you conclude from those
> axioms is meaningless.
Everybody else? If you think that 2 or 3 people on this thread are
evrybody you are incorrect once again. Some people did understand the
issue I was refering to right away but you ignore them and disqualify
them as *fools*.. How practical. And you got some nerve speaking about
intellectual honnesty.
You have not established that I do redefine terms and as a proof
everytime I was not sure about a specific term I clearly did not use it
and asked explanation.
Again these are your conclusions. Given your incoherence I take it as
a big compliment.
He did not agree to any of what you are saying: that's your
interpretation.
In first response, he just expressed a warning about not confusing
logical and physical and refers to what you call as linear aspect of
memory. I know have no disagreement with that.
In second response, he expresses a doubtful question as to why I would
not consider linear definition as monodimensional.
You are distorting his intensions in order to make a point and you use
a mathematical term *axiom* to present the wax of scientific
methodology, in order to reinforce your opinion. You have no clue of
what are the requirements behind scientific methodology.
> > //Not only and the fact that they are adjacent is not really the issue
> > but this description seems closer to what I mean. Thank you very much
> > for helping a better formulation of the issue. (I may have troubles
> > expressing the concept). This thread seems to be taking off after all.
> >
> > What is your insight on that.? Can OO in-memory mechanisms be helpful
> > on that matter? Most people here seem to believe the opposite. //
> >
> > JMDavitt did not explicitely express that he had a comprehension of
> > issues at hand he just aked the right question about a subject with
> > delimited scope which makes the triggering argument having sense. This
> > is why I told you at several occasions that you miss the point (in all
> > respect).
>
> It's easy to miss the point when trying to decypher meaning from
> gibberish. Mr. Davitt guessed and got lucky apparently. However, it
> seems he agrees your basic premises are false.
So now it's about luck? You are saying that such complex discussion is
subjected to luck for understanding issues? why not telepathy while you
are at it?
> > // I long ago added Alvin to my twit-filter. I forget whether that was
> > due
> > to a lack of intellectual honesty on his part or worse. That he might
> > pretend to make sense of what you wrote does not make it any more
> > sensible.//
> > I do not know any people accustomed to this board and I do not have any
> > preconceived idea about what they are or say. I just try to exchange
> > with sincerity and respect. Alvin or you are no exceptions. I conceive
> > that disagreeing with them on a specific matter as being an potential
> > opportunity to learn something. This process may not be as practical
> > as puting people on twit filter when they disagree with me but it is
> > rewarding.
>
> I don't put people in a twit-filter for disagreeing with me. I put them
> in there for wasting my time with intellectual dishonesty and/or
> assertive stupidity. While I might miss an extremely rare learning
> opportunity from one of them, I find I learn a lot more by focussing my
> time and effort with more fertile sources of learning opportunities.
How practical. It's just a shame that you can not establish anything
to backup you arrogance in pretending to be a knowledgeable source of
knowledge which would allow you to judge *stupidity* or a judge of
*intellectual honesty*.
> My guess is I will probably be next on your twit filter
> > and your next thread reference as being intellectualy dishonnest.
>
> Citing VSAM, a magnetic storage (DASD) technology, to justify statements
> regarding "in-memory" and RAM certainly borders on intellectual
> dishonesty.
I was refering to VSAM as an media independent reference for adressing
scheme and because you believed that bidimensional adressing scheme
were still to be invented. My point in using VSAM analogy was to make
you understand that bidimensionality and even tridimensionality is at
least 40 years old but you keep maitaining that a computational model
still needs to be invented.
However, I am still giving you the benefit of the doubt that
> RAM and "in-memory" might mean entirely different things to you due to
> the language barrier.
I do not need you to give me the benefit of the doubt. I need you to
participate in this thread in a more productive and targetted manner.
If you can't and you argument gets up to tell to go "fuck myself" then
stop right away because I will totally ignore this kind of comments.
> > // You have not established that anyone really made sense of what you
> > wrote. One person tried to rephrase what you wrote into something he
> > considered sensible, and he asked you for clarification at that time.
> > The other person is just a fool. Fools talk nonsense all the time.//
> > You are trying to establish nonsense on false assumptions and if
> > necessary you disqualify as *foolish* or *nonsensical* anything that
> > does not fit your perception of right and wrong.
>
> Well, if it makes you feel better to believe that, be my guest.
It is obvious. I have a few of your threads and I know now this is a
common behavior in your exchanges with other audiences.
> > 1) *Fool*, 2) *twit filter*, 3) *nonsense* 4) *lack of intellectual honnesty* -->
> > Is that your witchhunt arsenal to defend your positions when people
> > disagree with you and when you can not prove they are wrong.
>
> (numbering added for clarity of reference)
>
> No. That's 1) what I call people who are deficient in judgement, sense
> or understanding, 2) how I avoid wasting time on fools, 3) the name I
> use for words or signs having no intelligible meaning, and 4) how I
> identify people who are a waste of time.
Bla, Bla, Bla....
> This
> > attitude is scary and I do mean that in a friendly manner.
>
> If it were my attitude, your statement would have some relevance. As it
> is... [shrug]
>
>
> > // Nothing is really relevant to nonsense. I am trying to give you an
> > opportunity to rephrase what you are trying to communicate into
> > something sensible. You keep refusing and insisting that your prior
> > gibberish should make sense to people. Clearly, it does not.//
> > Sorry about that but I can not give more clarifications than I already
> > did to prove my good faith.
I am not convinced that we are in disagreement on fundamental issues
about data management as you seem to have shown some proficiency in
unerstanding of Relational issues. I just believe you make hasty
conclusions and that you have strong temper.
> > // I disagree. Confusing a property of a physical address space with a
> > property of a logical entity is nonsense. When I put a potato into
> > boiling water, I don't conclude that the boiling point of potatos is
> > 100
> > degrees celsius nor do I conclude it is a property of cooked potatos
> > as
> > opposed to potatos in general.//
> > I am not confusing anything you are.
>
Perhaps not now, but certainly in your earlier posts, where I and
others
noted the nonsensical nature of your statements, you were confusing
them--at least in what you wrote if not in what you intended to write.
<<This is silly. You change observation and resulting conclusions from
statement to statement with each new post. This is incoherence.>>
>
>
> So you use potatoes as an analogy
> > to explain bidimensionality of a relvar. It is totally irrelevant as
> > were your previous comment.
>
> I disagree. I suspect others would consider the analogy relevant. If any
> are still reading, perhaps one or another will voice that opinion.
No comment on that. You wishing somebody will come and help says it
all.
> > // Yet, having put a logical structure into a linear memory, you
> > expressed
> > a property of the linear memory as a property of the logical
> > structure.
> > Don't do that. It's nonsense even if you say it only applies to the
> > implementation of the logical structure in the physical address
> > space.//
> > No that would be totally silly.
>
> Hence the responses I and others gave when you said it.
>
>
> These are conclusions you are making
> > I stated that the SQL *physical* implementation on *current* DBMS
> > systems in necessarily bidimensional at run time because of the
> > addressing scheme used is a limiting factor to better representation
>
> First, your assertion that the implementations are necessarily
> bidimensional is false. Since that appears to be one of your axioms,
> anything you conclude from it is meaningless.
>
> Second, the computational models in OO use exactly the same kind of
> linear address space.
>
>
> > BUT I have never stated anywhere that a relvar is bidimensional.
>
> I agree. You stated that an SQL table is bidimensional, which is just as
> nonsensical.
False you are distorting the thruth. I said that SQL tables
implemented at run time are bidimensional when their adressing scheme
of memory is bidimensional. You are confusing logical and physical
again and again.
>
> The
> > latest part of the sentence is your interpretation.
>
> And the interpretation of several others here. If you string together
> words that mean A in english, it hardly makes sense for you to blame
> english speaking people for thinking you meant A when you in fact meant B.
I do not blame and thank people here for their patience when they help
me express complex issues.
> I suspect you
> > either misunderstood
>
> I understood what you wrote. Apparently, you did not mean what you
> wrote. Since you meant something other than what you wrote, of course, I
> misunderstood what you meant. There is no magic that conveys the correct
> meaning with random words.
Random words do not allow coherence. I have not changed a bit what I
am saying since the beginning to you.
Cimode
JXStern wrote:
> On Sun, 04 Jun 2006 17:25:04 GMT, Bob Badour
> <bba...@pei.sympatico.ca> wrote:
> >Apparently, in your addressing scheme, one may not access memory through
> >a single pointer. Instead, one must use three pointers.
>
> I just wandered (back) into the newsgroup yesterday for the first time
> in a while, and onto this thread in the middle of things, and have
> only read a few exchanges, but maybe this is the crux of Cimode's
> concerns about memory yada yada.
Yes. Through this thread, I am trying to involve people *not* to have
the usual RM vs the Rest of the World debate. But try to understand
how can the only valid model be better implemented given the available
implementation mecahnisms at hand OO is one of them.
I am convinced all people here are of good faith but just lack specific
information to allow them to communicate efficiently with other type of
audiences.
>
> Odd that this thread doesn't seem to use terms like "projection" or
> "composition" (maybe I did see "decomposition"). Or, y'know,
> "semantics".
semantics and terminology are necessary to bring coherence in RM
definition. Lack of commitment to precise definition bothers RM
knowledgeable audiences. For good reasons. Projections or
compositions have not been evocated yet because there was no context
yet for them to be evocated. What do you have in mind?
> The relational model really only uses one "relation", which is
> adjacency.
I do not agree with that. RM is about defining an infinity of
relations.
Perhaps this is another Cimode concept in the making.
Could you define precisely "Adjacency". I am not certain to what it
means to you.
You
> can have as many dimensions of adjacency as you like. You can
> reinterpret a dimension of adjacency as something else, like time
> sequence, but as soon as you do, you run across the limits of the
> relational model. Now, it is also the great strength of the
> relational model that it is built so simply, and the question is
> whether that strength is comprimised when we go to extend it.
I do not understand this argument. Could you ellaborate?
Cimode
imposes a serious limitation on separating logical from physical.
> As for "OO in-memory mechanisms," I think that such storage schemes
> should be described a one-dimensional, don't you?.
Yes but most adresses are relative not absolute which makes it
necessary to range them in (Row/Column or Block) types of addressing
scheme. Which make the implementations bidimensional or
tridimensional.
After all, each
> instance is allocated a bunch of bits from a linear address space.
> Just because it's apparently a simple matter to pass an address
> around doesn't mean that the content of all addresses are easily
> accessed. MIPS chips and Intel chips have very different techniques
> for managing large memory fields. But that fact doesn't have anything
> to do with OO concepts, does it? Well, neither does the choice of
> storage technique have anything to do with relational concepts or SQL.
Not just storage but also the way operations are performed.
Cimode
Bob Badour wrote:
> JXStern wrote:
>
> > On Sun, 04 Jun 2006 17:25:04 GMT, Bob Badour
> > <bba...@pei.sympatico.ca> wrote:
> >
> >>Apparently, in your addressing scheme, one may not access memory through
> >>a single pointer. Instead, one must use three pointers.
> >
> > I just wandered (back) into the newsgroup yesterday for the first time
> > in a while, and onto this thread in the middle of things, and have
> > only read a few exchanges, but maybe this is the crux of Cimode's
> > concerns about memory yada yada.
> >
> > Odd that this thread doesn't seem to use terms like "projection" or
> > "composition" (maybe I did see "decomposition"). Or, y'know,
> > "semantics".
>
> We haven't gotten that far yet. We are still trying to make sense of
> what Cimode wants.
issue here and you want to make him believe he did not concentrating
attention on me. Concentrate on the subject at hand.
Bob Badour
> Bob Badour wrote:
>
>>JXStern wrote:
>>
>>
>>>On Sun, 04 Jun 2006 17:25:04 GMT, Bob Badour
>>><bba...@pei.sympatico.ca> wrote:
>>>
>>>
>>>>Apparently, in your addressing scheme, one may not access memory through
>>>>a single pointer. Instead, one must use three pointers.
>>>
>>>I just wandered (back) into the newsgroup yesterday for the first time
>>>in a while, and onto this thread in the middle of things, and have
>>>only read a few exchanges, but maybe this is the crux of Cimode's
>>>concerns about memory yada yada.
>>>
>>>Odd that this thread doesn't seem to use terms like "projection" or
>>>"composition" (maybe I did see "decomposition"). Or, y'know,
>>>"semantics".
>>
>>We haven't gotten that far yet. We are still trying to make sense of
>>what Cimode wants.
>
> You are trying to make sense. JXStern has again addressed the real
> issue here and you want to make him believe he did not concentrating
> attention on me. Concentrate on the subject at hand.
I did concentrate on the subject at hand. I objected to his
characterization of the relational model.
Bob Badour
The hell they are! At this time in this discussion they are nothing more
than meaningless symbols. You have yet to provide any definition or any
reference to a definition.
If all you want to do is engage in mental masturbation, I suggest you do
it in private.
>>>Besides when was the last time you checked memory architectures?
>>
> //I suggest you consider the name of this newsgroup. It is not
> comp.intel.architecture.64bit and it is not comp.intel.mmu.64bt//
> You have totally ellided that question.
I did not answer the question because neither the question nor the
answer are relevant. If you expect people here to understand terms that
are never used in this newsgroup, you will need to define them or point
to some definition. Duh!
> The name of this newsgroup is comp.databases.theory and it is a ground
> for discussing all theory related to databases including implementation
> theory.
When was the last time you read a paper discussing a theory of computing
that didn't bother to define a computational model? Never?
>>If you want to discuss a specific computational model, you will have to
>>provide some sensible definition of that model. Even with segmented
>>memory, the address space is linear. Even with virtual memory, the
>>address space is linear. Even with paged memory, the address space is
>>linear.
>
> You keep bringing computational model again.
Of course, I do. We cannot even begin to discuss this topic sensibly
until we know what fucking computational model we are using. Idiot.
While I told you that segmented memory has nothing to do
> with physical addressing scheme for relative position of data.
But you have claimed repeatedly that linear addressing is bidimensional
and you have stated that this bidimensionality applies to logical
entities with N dimensions.
>>Are you suggesting that current memory architectures are non-segmented,
>>non-virtual, non-paged, non-linear architectures? Are you suggesting
>>that this would somehow become relevant to the theoretical computational
>>model?
>
> I suggested that this high level not low level.
You are nothing but an ignorant crank. Go waste somebody else's time.
Idiot. Plonk.
Cimode
adresses it can be only monodimensional (What BobBadour refers as
linear). But most operations are done through relative calculation of
hexadecimal adresses. Which is why representation of the above is
incorrect. Below would be closer to reality
Absolute adress/Relative Adress
ColumnAdress1 ColumnAdress2
RowAdress1> 0/0 : pinky 8/0 : box
RowAdress2> 1/1 : bit 9/1: crate
RowAdress3> 2/2 : crumb 10/2 : pallet
RowAdress4> 3/3 : chunk 11/3 : container
RowAdress5> 4/4 : unit 12/4 : truck
RowAdress6> 5/5 : finger 13/5 : train
RowAdress7> 6/6 : bar 14/6 : house
RowAdress8> 7/7 : pack 15/7 : big_dog
After data pages are loaded into memory and showplan are determined how
do you think operations of selection are referencing data in memory?
Cimode
Bob Badour wrote:
> Cimode wrote:
> > Bob Badour wrote:
> >
> >>JXStern wrote:
> >>
> >>
> >>>On Sun, 04 Jun 2006 17:25:04 GMT, Bob Badour
> >>><bba...@pei.sympatico.ca> wrote:
> >>>
> >>>
> >>>>Apparently, in your addressing scheme, one may not access memory through
> >>>>a single pointer. Instead, one must use three pointers.
> >>>
> >>>I just wandered (back) into the newsgroup yesterday for the first time
> >>>in a while, and onto this thread in the middle of things, and have
> >>>only read a few exchanges, but maybe this is the crux of Cimode's
> >>>concerns about memory yada yada.
> >>>
> >>>Odd that this thread doesn't seem to use terms like "projection" or
> >>>"composition" (maybe I did see "decomposition"). Or, y'know,
> >>>"semantics".
> >>
> >>We haven't gotten that far yet. We are still trying to make sense of
> >>what Cimode wants.
> >
> > You are trying to make sense. JXStern has again addressed the real
> > issue here and you want to make him believe he did not concentrating
> > attention on me. Concentrate on the subject at hand.
>
> I did concentrate on the subject at hand. I objected to his
> characterization of the relational model.
Yes. but only in the last comments you posted.
You objected to something that did not require objection as it was
never put in doubt which basically makes most of your previous
assertions totally irrelevant.
Cimode
> If all you want to do is engage in mental masturbation, I suggest you do
> it in private.
Have you noticed that mental masturbation is very mechanical/repetitive
action? The repetitiveness and the predicatibility of your
argumentation (nosense, crank, idiot, twit filter) make you certainly
more predisposed to carry such activity. Oh no! At least masturbation
produces something. In your case nothing is produced but a big bag of
crappola making feel better and more secure about dumb certainties.
> >>>Besides when was the last time you checked memory architectures?
> >>
> > //I suggest you consider the name of this newsgroup. It is not
> > comp.intel.architecture.64bit and it is not comp.intel.mmu.64bt//
> > You have totally ellided that question.
>
> I did not answer the question because neither the question nor the
> answer are relevant. If you expect people here to understand terms that
> are never used in this newsgroup, you will need to define them or point
> to some definition. Duh!
>
>
> > The name of this newsgroup is comp.databases.theory and it is a ground
> > for discussing all theory related to databases including implementation
> > theory.
>
When was the last time you read a paper discussing a theory of
computing
that didn't bother to define a computational model? Never?
I told you a hundred times there was no usefulness into defining a new
computational model for understanding such simple issues.
Do you sincerely believe that anybody who wants to exchange on
in-memory progammatic issues needs to deploy an entire model?
>
>
> >>If you want to discuss a specific computational model, you will have to
> >>provide some sensible definition of that model. Even with segmented
> >>memory, the address space is linear. Even with virtual memory, the
> >>address space is linear. Even with paged memory, the address space is
> >>linear.
> >
> > You keep bringing computational model again.
>
> Of course, I do. We cannot even begin to discuss this topic sensibly
> until we know what fucking computational model we are using. Idiot.
There we go, here is an additional insult. *idiot* added to the
arsenal. You are pathetically predictable. As I told you I will
totally ignore posts including insults and won't bother responding.
> While I told you that segmented memory has nothing to do
> > with physical addressing scheme for relative position of data.
>
> But you have claimed repeatedly that linear addressing is bidimensional
> and you have stated that this bidimensionality applies to logical
> entities with N dimensions.
>
>
> >>Are you suggesting that current memory architectures are non-segmented,
> >>non-virtual, non-paged, non-linear architectures? Are you suggesting
> >>that this would somehow become relevant to the theoretical computational
> >>model?
> >
> > I suggested that this high level not low level.
>
You are nothing but an ignorant crank. Go waste somebody else's time.
Idiot. Plonk.
*crank* added to your limited lexic. I will not respond to this kind
of garbage. But I will define you as a person. through a limited bag
of words your are using repetitively on this thread but on all threads
where you brought your *help* an *knowledge*
(*nonsense*, *nonsensical*, *idiot*, *crank*, *plonk*, *twit-filter*,
*fuck yourself*).
PASCAL was right after anybody pretending to be helpful online is
indeed a crank.
Cimode
*idiot*,
*nonsense*,
*nonsensical*,
*plonk*,
*crank*,
*fuck yourself*
+ *do not waste my time* whining.
Cimode
onto saying that I would need to define a computational model first is
because of your confusion between logical and physical layer. There
are about a zillion computational models defining operation logical
rules for organizing memory and processes and are specifically targeted
logical implementations.
You are trying to get me to define something totally unuseful to the
context of defining the way referencing is defined according to a
specific memory bus.
I do not believe that you got the nerve saying that I confuse logical
and physical layer.
Besides, I have given serious effort to answer each objection you
raised (except the one with insults) but you skipped so many of the
questions I have adressed you that it clearly points out your selective
attitude into ignoring things that do not fit your perception of
what's' right or wrong.
JXStern
>I am convinced all people here are of good faith but just lack specific
>information to allow them to communicate efficiently with other type of
>audiences.
I think there are some real disagreements, too.
>> Odd that this thread doesn't seem to use terms like "projection" or
>> "composition" (maybe I did see "decomposition"). Or, y'know,
>> "semantics".
>semantics and terminology are necessary to bring coherence in RM
>definition. Lack of commitment to precise definition bothers RM
>knowledgeable audiences. For good reasons. Projections or
>compositions have not been evocated yet because there was no context
>yet for them to be evocated. What do you have in mind?
When the example was representing parts of a Rubik's Cube, I thought
the projection and composition topics were relevant.
In comparisons of object vs. relational practices, the issue of
whether a relation needs to be reified and/or explicitly labelled (say
as an association table) always comes up. The logical relation here
may be a semantic one, so that's the way to have commonality between
the two models. And whatever new features are introduced that bridge
the two sides, should IMHO often be described in semantic terms.
>
>> The relational model really only uses one "relation", which is
>> adjacency.
>I do not agree with that. RM is about defining an infinity of
>relations.
>
>Perhaps this is another Cimode concept in the making.
>
>Could you define precisely "Adjacency". I am not certain to what it
>means to you.
>
>You
>> can have as many dimensions of adjacency as you like. You can
>> reinterpret a dimension of adjacency as something else, like time
>> sequence, but as soon as you do, you run across the limits of the
>> relational model. Now, it is also the great strength of the
>> relational model that it is built so simply, and the question is
>> whether that strength is comprimised when we go to extend it.
>I do not understand this argument. Could you ellaborate?
When you have a number of fields in a row, what do you know about
them? Only that they all depend on the PK. The column name may
provide an additional hint of just what the relationship is (eg
"father", "licence_number", "isActive", but the nature of the
relationship is invisible to the RM. Domains and constraints are
additional hints, but no more. All we know is that in a cannonical
representation of whatever the application area is, we want to store
this column with that PK.
So, what is the alternative to an "adjacency-only" RM? Something
extensible and messy, where you explicitly type relations of fields to
keys, the types coming out of an ontology, comprising entirely new
domains of metadata about the primary model.
If we're not getting into stuff like that, maybe we're not on the
right road in new database technologies.
J.
Cimode
JXStern wrote:
> On 5 Jun 2006 03:41:34 -0700, "Cimode" <cim...@hotmail.com> wrote:
> >I am convinced all people here are of good faith but just lack specific
> >information to allow them to communicate efficiently with other type of
> >audiences.
>
> I think there are some real disagreements, too.
hand.
> >> Odd that this thread doesn't seem to use terms like "projection" or
> >> "composition" (maybe I did see "decomposition"). Or, y'know,
> >> "semantics".
> >semantics and terminology are necessary to bring coherence in RM
> >definition. Lack of commitment to precise definition bothers RM
> >knowledgeable audiences. For good reasons. Projections or
> >compositions have not been evocated yet because there was no context
> >yet for them to be evocated. What do you have in mind?
>
> When the example was representing parts of a Rubik's Cube, I thought
> the projection and composition topics were relevant.
Yes they are nut operations are relvar seem a little bit complicated to
be aborded straight away. I do believe that defining an economical
loading process for IO/Disk values extracted from domains is a primary
issue that needs to be solved first. insuch perspective there's a need
to define an adressing scheme that is more coherent with domain
definitions than direct image implentation. After all, relations are
multidimensional variables drawing values from specific domains.
> In comparisons of object vs. relational practices, the issue of
> whether a relation needs to be reified and/or explicitly labelled (say
> as an association table) always comes up. The logical relation here
> may be a semantic one, so that's the way to have commonality between
> the two models. And whatever new features are introduced that bridge
> the two sides, should IMHO often be described in semantic terms.
RM and OO are difficult to compare as the are of different nature. RM
is a logical model
based on set theory that regulates logically operations. OTOH, OO is a
set of computing mechanisms that have certain reccuring characteristics
that are mainly useful at implementation level. Question is what can
these mechanisms can allow more economical representation and
operations of relvar.
> >> The relational model really only uses one "relation", which is
> >> adjacency.
> >I do not agree with that. RM is about defining an infinity of
> >relations.
> >
> >Perhaps this is another Cimode concept in the making.
> >
> >Could you define precisely "Adjacency". I am not certain to what it
> >means to you.
>
>
> >
> >You
> >> can have as many dimensions of adjacency as you like. You can
> >> reinterpret a dimension of adjacency as something else, like time
> >> sequence, but as soon as you do, you run across the limits of the
> >> relational model. Now, it is also the great strength of the
> >> relational model that it is built so simply, and the question is
> >> whether that strength is comprimised when we go to extend it.
> >I do not understand this argument. Could you ellaborate?
>
> When you have a number of fields in a row, what do you know about
> them? Only that they all depend on the PK. The column name may
> provide an additional hint of just what the relationship is (eg
> "father", "licence_number", "isActive", but the nature of the
> relationship is invisible to the RM.
I am not sure what you mean by invisible? Could you ellaborate on
that?
Domains and constraints are
> additional hints, but no more. All we know is that in a cannonical
> representation of whatever the application area is, we want to store
> this column with that PK.
Domains are much more than hints as they are a fundamental issue of RM
as it is what allows the definition of data types on attributes.
Therefore relations are domain bound. Don't tell that to relational
advocates? They may burn you in public place. Constraints are also a
fundamental issue in RM as it is what allows to declare a sub ensemble
of possible values extracted from a domain. There is no way to get
around these two into implementing RM.
> So, what is the alternative to an "adjacency-only" RM?
RM defines tuple at logical. Based on predicates logic, RM allows to
make assertions such as
EMP# is named NAME# and earns SALARY# $...It dictates that all tuples
responding to that predicate must be a boolean value of TRUE for all
occurences of a tuple. NAME# and SALARY# are values extracted from a
sub ensemble of a specific domain of values. RM dictates precise rules
to define all relationship between these values which allows to relate
them in the sense you asked.
> extensible and messy, where you explicitly type relations of fields to
> keys, the types coming out of an ontology, comprising entirely new
> domains of metadata about the primary model.
>
> If we're not getting into stuff like that, maybe we're not on the
> right road in new database technologies.
I dont' exactly understand such pessimism. could you ellaborate?
> J.
Bob Badour
I once again object to the silly idea that the RM depends on location.
Something
> extensible and messy, where you explicitly type relations of fields to
> keys, the types coming out of an ontology, comprising entirely new
> domains of metadata about the primary model.
>
> If we're not getting into stuff like that, maybe we're not on the
> right road in new database technologies.
No matter how complex one makes things, one will always have an eternal
predicate. (See Goedel.)
Creating more complex structures does not affect the observation that
computers do not think; they compute. A computer will happily perform
symbolic manipulations of more complex structures. However, humans will
not understand those structures as clearly, and the greater the
complexity the more likely the humans writing the programs will fail.
Bob Badour
Oops, that should be "external" not eternal.
JXStern
<bba...@pei.sympatico.ca> wrote:
>> So, what is the alternative to an "adjacency-only" RM?
>
>I once again object to the silly idea that the RM depends on location.
RM depends on algebra if you like, set theory if you prefer.
My comments about "adjacency" aren't meant to imply physical location,
just an untyped (because supposedly universal) association. But
"association" has too many connotations to use as the term, either.
I might make the same protest against set theory itself, if set theory
made the same pretense at domain representation that RM does. But
everyone knows set theory is a low-level, if powerful (maybe even
universal) tool. If that's all you see in RM, then fine. But I look
at the idea of a normalized data model, and see an attempt to do
something above and beyond a raw set theory, and in this attempt, it
could use some new thinking, features, enhancements, extensibility,
whatever.
J.
Cimode
refering to is not at logical level but at physical level. set theory
(logical) is location independent but naturally it seems you are
considering it at physical level of implementation. My guess, is that
set theory is not a sufficient math tool for responding to question of
resource use and mutualization at physical level.
On such perpective, the notion of *distance* come handy because it may
help solve resources issues onto representing economically relvars and
allowing a better support of operations performed. Using vectorial
representation for expressing relvars through multidimensional
coordinate referentials may help optimize computing effort required to
represent multidimensionnal variables because vectors are a
mathematical tool that is particularily adapted to make a link between
algebric set theory and spatial math that applies to implementation
requirement.
x
"J M Davitt" <jda...@aeneas.net> wrote in message
news:H6Ggg.54099$P2.4...@tornado.ohiordc.rr.com...
> As for "OO in-memory mechanisms," I think that such storage schemes
> should be described a one-dimensional, don't you?. After all, each
> instance is allocated a bunch of bits from a linear address space.
> Just because it's apparently a simple matter to pass an address
> around doesn't mean that the content of all addresses are easily
> accessed. MIPS chips and Intel chips have very different techniques
> for managing large memory fields. But that fact doesn't have anything
> to do with OO concepts, does it? Well, neither does the choice of
> storage technique have anything to do with relational concepts or SQL.
I remember that the organization of the video memory of sinclair spectrum
home computers was very interesting and very linear. :-)
x
"Keith H Duggar" <dug...@alum.mit.edu> wrote in message
news:1149479774.2...@f6g2000cwb.googlegroups.com...
> Cimode wrote :
> > Bob Badour :
> > > What are the two dimensions? Can you name them?
> >
> > For bidimensional RAM's, the 2 dimensions are RowAddress
> > and ColumnAddress For tridimensional RAM's (64bit
> > architectures) the 3 dimensions are Block Adress,
> > RowAddress, ColumnAddress Does that make sense? It was
> > written above.
> Suppose we have a 16-bit architecture with 2^16 memory
> cells. How many dimensions is the memory?
from: http://www.alfonsomartone.itb.it/fztsmo.html
10 POKE USR "a"+1,BIN 0001000
20 POKE USR "a"+2,BIN 0011100
30 POKE USR "a"+3,BIN 0111110
40 POKE USR "a"+4,BIN 1111111
50 POKE USR "a"+5,BIN 0111110
60 POKE USR "a"+6,BIN 0011100
70 POKE USR "a"+7,BIN 0001000
x
coprocessor registers ?
How about VGA memory ?
x
"Bob Badour" <bba...@pei.sympatico.ca> wrote in message
news:KXFgg.17468$A26.4...@ursa-nb00s0.nbnet.nb.ca...
> You claim that physical memories are multidimensional; however, on the
> one occasion I recall anyone using a computational model with multiple
> dimensions of memories, it was used in the constructive proof that a
> single-tape turing machine is just as expressive as a multiple-tape
> turing machine.
But that only say that the usefulness of turing machines should not be
decided based on expressivity. :-)
> I disagree. Confusing a property of a physical address space with a
> property of a logical entity is nonsense. When I put a potato into
> boiling water, I don't conclude that the boiling point of potatos is 100
> degrees celsius nor do I conclude it is a property of cooked potatos as
> opposed to potatos in general.
> Yet, having put a logical structure into a linear memory, you expressed
> a property of the linear memory as a property of the logical structure.
> Don't do that. It's nonsense even if you say it only applies to the
> implementation of the logical structure in the physical address space.
Some people knows that warm water freezes more rapidly than cold water, but
the scientists had trouble explaining it :-)
x
"Cimode" <cim...@hotmail.com> wrote in message
news:1149432425.4...@h76g2000cwa.googlegroups.com...
>
> Alfredo Novoa,
>
> //His posts are extremely wordy and nonsensical. If he had a better
> grasp of the language, I think he would communicate more succinctly and
> make
> more sense.//
> I agree on that they are wordy and nonsensical, but I would not expect
> something a lot more coherent with a better grasp of the language.//
> On that I won't argue, as my communication is not as efficient as I
> would like it to be
Those who argue with a fool risk that people will not perceive the
difference between them.
x
"x" <x...@not-exists.org> wrote in message news:e6410p$fsr$1...@nntp.aioe.org...
>
> "Cimode" <cim...@hotmail.com> wrote in message
> news:1149432425.4...@h76g2000cwa.googlegroups.com...
> > On that I won't argue, as my communication is not as efficient as I
> > would like it to be
>
> Those who argue with a fool risk that people will not perceive the
> difference between them.
fool:
3. a person who has been tricked or deceived
into appearing silly or stupid: to make
a fool of someone.
x
"x" <x...@not-exists.org> wrote in message news:e6410p$fsr$1...@nntp.aioe.org...
> Those who argue with a fool risk that people will not perceive the
> difference between them.
fool [2] (fuel) n.
1. an English dessert of crushed, cooked
fruit mixed with cream or custard and
served cold: gooseberry fool.
erk
Are you sure? :-)
x
>
> Bob Badour wrote:
> // Alfredo has shown no indication whatsoever of confusing anything. *If*
> your only goal is to insult the people who are trying to help you//
> This is BS. Prove it. I have not insulted Alfredo or anybody on this
> board. If you feel insulted because I pointed out that some of your
> comments were totally irrelevant or wrong because they were is not an
> insult.
> //, you
> can go fuck yourself.//
> Bob you are going too far. If this is the way you *help* people on
> boards? This kind of declaration are totally contradicting what you
> present as noble intentions and supposed to be meaningful. I did
> tolerate until now your confusions and I will not tolerate to be
> insulted and simply ignore this kind of post. You should be ashamed of
> yourself.
His "excuse" is the word *if* he used.
> > Alfredo has shown no indication whatsoever of confusing anything. *If*
> > your only goal is to insult the people who are trying to help you, you
> > can go fuck yourself.
x
> Cimode wrote:
> >
> > //A SQL table with three attributes is always three dimensional
> > independently of how it is implemented.//
> >
> > At logical level yes but not at physical level.
> At any level, Cimode. If you don't mean to refer to the SQL table, then
> refer to something else that you do mean. *Any triplet, though,
> represents three dimensions.*
Huh ?!?
> > //<<I suppose that you know how to represent a cube with a table.>> It
> > is
> > an analogy used for communication's sake. You misread and
> > misunderstood my comment. I said that a face of a cube is
> > bidimensional and is a comparable to what a SQL Table is to a relvar.
> And any representation of a face of a cube is *bidimensional*. However,
> any representation of the cube is three dimensional, or it no longer
> represents a cube. Don't confuse the projection of a cube with a cube.
I would say that given the fact that the cube is 3D, the face coordinates
are triplets.
Cimode
The cube is a perfect example of tridimensional. Each point in the
cube can be referenced trough a 3 point coordinate system. Now, each
face is bidimensional and each point can be referenced through both a 2
point coordinate system AND a 3 point coordinate system. What changes
is only the referential and origin.
Bob Badour
> On Mon, 05 Jun 2006 23:59:46 GMT, Bob Badour
> <bba...@pei.sympatico.ca> wrote:
>
>>>So, what is the alternative to an "adjacency-only" RM?
>>
>>I once again object to the silly idea that the RM depends on location.
>
> RM depends on algebra if you like, set theory if you prefer.
>
> My comments about "adjacency" aren't meant to imply physical location,
> just an untyped (because supposedly universal) association.
You are suggesting that a symmetric n-ary structure is untyped. I disagree.
But
> "association" has too many connotations to use as the term, either.
Explain to me how you think an asymmetric binary structure expresses
more than the symmetric n-ary structure.
> I might make the same protest against set theory itself, if set theory
> made the same pretense at domain representation that RM does. But
> everyone knows set theory is a low-level, if powerful (maybe even
> universal) tool.
Low-level? That's a rather dumb thing to say. Set theory is a high-level
abstraction of relatively modern invention as is predicate logic. Both
are founded on thousands of years of advances in mathematics.
If that's all you see in RM, then fine.
Please don't try to tell me I see your fantasies in anything. That's
just plain old ego-centric lunacy.
But I look
> at the idea of a normalized data model, and see an attempt to do
> something above and beyond a raw set theory,
Again, what you say seems nonsensical and rather dumb. If you mean a
normalized schema, then that is a direct application of set theory and
the relational data model, which is itself equivalent to set theory. To
characterize a direct application of something as "above and beyond" the
thing is meaningless gibberish.
and in this attempt, it
> could use some new thinking, features, enhancements, extensibility,
> whatever.
Before you voice such a conclusion, I suggest you should exhibit better
understanding of the old thinking.
Cimode
magical *twit filter* to discard my post but I want to point out out
the issue of his misunderstanding and bad faith on this thread.
The object of the argument was that I considered physical
representation of SQL table on all current implementation as purely
bidimensional or tridimensional depending on the adressing scheme used
at physical level of RAM implementation. Mister BB has advocated
the opposite stating that physical implementation are multidimensional
and that stated that RAM adresses are linear.
I state that BB is wrong in saying RAM SQL tables representations are
multidimensional...
A multidimensional physical representation of a N dimension relvar
supposes it can be represented through an N-ary coordinate system
equivalent at physical level. Otherly said, any SQL datum location on
that physical memory should have then an N-ary system of
coordinates to locate it in RAM.
Such system does not exist.
Most RAM architectures memory is addressed with a 32-bit address (or
36-bit if PAE is enabled). But those addresses are translated by
the memory controller to a physical address that identifies which bank,
row, and column the memory actually resides in. In latest Dual
Core Opteron CPU's the memory controller has been directly integrated
into the CPU which allows direct physical referencing without need
of translation and took away the need for using linear adressing.
That proves 2 things:
> When stating that RAM is linear, BB has proved that he ignores what
a physical memory architecture is. He proved he does not
make a difference between a logical linear adressing scheme at CPU
level and a physical adressing scheme at RAM (memory controller). I
clearly pointed out this confusion to him and he chose to persist.
> To be considered multidimensional at physical level a SQL Table
should have all the datum embodying it located through an N-ary
physical adressing scheme as opposed to a trinary system. For
instance, considering the following example
SQL Table
Datum1, Datum2, Datum3, Datum4
Datum5, Datum6, Datum7, Datum8
Datum9, Datum10, Datum11, Datum12
In a multidimensional physical RAM, it should be possible to represent
and locate it at least through N physical coordinates.
--> MEMORY CONTROLER
locates Datum1 at (A1, A2, A3, A4...A-N)
locates Datum2 at (A1, A6, A7, A4...A-N)
locates Datum3 at (A1, A2, A3, A4...A-N)
and so forth....
Needless to such a physical RAM system does not exist. Therefore, it
proves SQL Table is NOT multidimensional at physical level. Its
representation and handling is necessarily determined by the RAM
adressing scheme used by the memory controler.
To make sure I was not missing anything which could have proved me
wrong I have re-read the thread and even checked BB link to try to
understand his point of view. It was a pure waste of time as any of
the reading done has been relevant to subject treated. Considering the
following:
> BB claimed that I insulted people without proving it. He used this occasion to tell me "go fuck myself". As a response, I have stated that I would only respond to his non insulting posts.
> By respect, I have clearly provided responses to all questions brought by the so-called *educator(s)*. The opposite is not true.
> I have pointed out to at several occasions the level of confusion at BB and demonstrated through logical argumentation. His only response was insults and irrelevant comments.
I consider that unless he acknowledges he was wrong or proves me wrong
responding to this question, he just has lost all credibility I was
willing to give him. Listenning. Probable answers:
> No response...(let's see if the *plonk* system works ;))
> Irrelevant and off topic responses (talking about something else to divert attention on current subject)
> Insults
> ?
Bob Badour wrote:
> Alfredo Novoa wrote:
>
> > Cimode ha escrito:
> >
> >> The question is whether OO in-memory
> >>mechanisms could support such effort. And how?
> >
> > The answer is evident to me: OO has nothing to offer. Both things are
> > completely unrelated.
>
> Hear! Hear!
Cimode
For instance, considering the following SQL Table
Datum1, Datum2, Datum3, Datum4
Datum5, Datum6, Datum7, Datum8
Datum9, Datum10, Datum11, Datum12
In a multidimensional physical RAM, it should be possible to represent
and locate it at least through N physical coordinates.
--> MEMORY CONTROLER
locates Datum1 at (A1, A2, A3, A4...A-N)
locates Datum2 at (A1, A6, A7, A4...A-N)
locates Datum3 at (A1, A2, A3, A4...A-N)
and so forth....
Needless to such a physical RAM system does not exist. Therefore, it
proves SQL Table is NOT multidimensional at physical level. Its
representation and handling is necessarily determined by the RAM
adressing scheme used by the memory controler.
To make sure I was not missing anything which could have proved me
wrong I have re-read the thread and even checked BB link to try to
understand his point of view. It was a pure waste of time as any of
the reading done has been relevant to subject treated.
Considering the following:
> BB claimed that I insulted people without proving it. He used this occasion to tell me "go fuck myself". As a response, I have stated that I would only respond to his non insulting posts.
> By respect, I have clearly provided responses to all questions brought by the so-called *educator(s)*. The opposite is not true.
> I have pointed out to at several occasions the level of confusion at BB and demonstrated through logical argumentation. His only response was insults and irrelevant comments.
I consider that unless he acknowledges he was wrong, which I strongly
doubt, or proves me wrong responding to this question, he just has
Jay Dee
> I know BB won't probably read this thread as he probably used his
> magical *twit filter* to discard my post but I want to point out
>
> The object of the argument was that I considered physical
> representation of SQL table on all current implementation as purely
> bidimensional or tridimensional depending on the adressing scheme used
> at physical level of RAM implementation. Mister BB has advocated
> the opposite stating that physical implementation are multidimensional
> and that stated that RAM adresses are linear.
Dimension, when discussing databases and memory, is two
different words.
Suggesting that the memory model of the machine on which
a system is implemented affects the arity of the data in
a database indicates confusion of the different meanings
the word has.
Cimode
Jay Dee wrote:
> Cimode wrote:
> > I know BB won't probably read this thread as he probably used his
> > magical *twit filter* to discard my post but I want to point out
> > the issue of his misunderstanding and bad faith on this thread.
> >
> > The object of the argument was that I considered physical
> > representation of SQL table on all current implementation as purely
> > bidimensional or tridimensional depending on the adressing scheme used
> > at physical level of RAM implementation. Mister BB has advocated
> > the opposite stating that physical implementation are multidimensional
> > and that stated that RAM adresses are linear.
>
> Dimension, when discussing databases and memory, is two
> different words.
the same as dimension at mathematical level we agree on that. I am
exclusively refering at the second to consider physical aspects of
memory. That is why debate at logical level is totally irrelevant. I
refer to N dimension as being refered by an N system of coordinates.
> Suggesting that the memory model of the machine on which
> a system is implemented affects the arity of the data in
> a database indicates confusion of the different meanings
> the word has.
I believe there's confusion but not where you think. I have clearly
defined dimension as not being refering to logical definition. We are
*exclusively* at physical level.
Reread the thread please. I state that the memory model that regulates
the RAM system at physical level limits the implementation of
multidimensionality as is defined at logical level. I have not said
that it would redefine the muldimensionality at logical level, that
would be absurd. We all know a relvar is a purely multidimensional
variable. But I stated and proved the current physical implementation
do not allow to represent that multidimensionality....
Cimode
model while I stated that it restricts its implementation. It is not
the same thing!!.
Unless you can prove that memory model does in fact implement
*physically* multidimensionality (mathematically speaking not a logical
standpoint). I respectfully believe you are making the confusion.
paul c
> ...
> I state that BB is wrong in saying RAM SQL tables representations are
> multidimensional...
I doubt if he said any such thing. More accurate to say that RAM can
represent multidimensional SQL tables, courtesy of human interpretation.
A memory controller has no idea what an SQL table is. OO advocates seem
to be forever boxing themselves into such corners because of neglecting
to separate logical from physical. Alfredo put it exactly when he said
the two are unrelated. Maybe one could define relations to describe
this but it would be pointless since the HW mfr's are unlikely to burn a
dbms into their controllers.
Cimode
paul c wrote:
> Cimode wrote:
> > ...
> > I state that BB is wrong in saying RAM SQL tables representations are
> > multidimensional...
> > ...
>
> I doubt if he said any such thing.
budimensional or tridimensional) which is equivalent to advocate it is
multidimensional. In fact, I don't exactly know what he tries to
state...
More accurate to say that RAM can
> represent multidimensional SQL tables, courtesy of human interpretation.
BS. Human interpretation is a subjective concept. I stated clearly
defined argument based on knowledge of memory physical architectures
not on some BS computational model.
> A memory controller has no idea what an SQL table is.
Of course it does not. We are at physical mechanized level.
OO advocates seem
> to be forever boxing themselves into such corners because of neglecting
> to separate logical from physical. Alfredo put it exactly when he said
> the two are unrelated. Maybe one could define relations to describe
> this but it would be pointless since the HW mfr's are unlikely to burn a
> dbms into their controllers.
I am not an OO advocate I dont' even know about OO. I am just
observing a simple elementary fact on physical level and drawing a
conclusion from it. I just don't understand what makes so complex to
understand...
Cimode
paul c wrote:
> Cimode wrote:
> > ...
> > I state that BB is wrong in saying RAM SQL tables representations are
> > multidimensional...
> > ...
>
> I doubt if he said any such thing. More accurate to say that RAM can
> represent multidimensional SQL tables, courtesy of human interpretation.
> A memory controller has no idea what an SQL table is. OO advocates seem
> to be forever boxing themselves into such corners because of neglecting
> to separate logical from physical. Alfredo put it exactly when he said
> the two are unrelated. Maybe one could define relations to describe
> this but it would be pointless since the HW mfr's are unlikely to burn a
> dbms into their controllers.
about what you know then fine...I really don't care.
It's not about boxing it's about discussing a limited scope issue which
is physical implementation. Nobody confuses logical and physical here.
It's you who refuse to discuss physical implementation issues.
What do you think it would pointless to address such issue? The fact
that HW Manufacturers won't do it is not an argument to justify it's
pointless to discuss the issue of implementation.
paul c
> paul c wrote:
>> Cimode wrote:
>>> ...
>>> I state that BB is wrong in saying RAM SQL tables representations are
>>> multidimensional...
>>> ...
>> I doubt if he said any such thing. More accurate to say that RAM can
>> represent multidimensional SQL tables, courtesy of human interpretation.
>> A memory controller has no idea what an SQL table is. OO advocates seem
>> to be forever boxing themselves into such corners because of neglecting
>> to separate logical from physical. Alfredo put it exactly when he said
>> the two are unrelated. Maybe one could define relations to describe
>> this but it would be pointless since the HW mfr's are unlikely to burn a
>> dbms into their controllers.
> If you believe sticking an 'OO advocate' makes you feel more secure
> about what you know then fine...I really don't care.
>
> It's not about boxing it's about discussing a limited scope issue which
> is physical implementation. Nobody confuses logical and physical here.
> It's you who refuse to discuss physical implementation issues.
>
> What do you think it would pointless to address such issue? The fact
> that HW Manufacturers won't do it is not an argument to justify it's
> pointless to discuss the issue of implementation.
>
This thread's subject says "OO programming proponents". Nobody called
you one.
I'm fine with discussing physical implementation issues. I don't see
how one can realize a theory without that. There's some from me and
others in this group's archives about it but I wish there were more.
However, I don't see much potential in memory controllers since the kind
mentioned have no programming interface that a dbms implementer could
get his or her hands on.
p
Cimode
specifically this issue, bringing back totally irrelevant comments
about logical issues when we are specifically dealing physical
implementation.
> I'm fine with discussing physical implementation issues. I don't see
> how one can realize a theory without that. There's some from me and
> others in this group's archives about it but I wish there were more.
Good for you..This could have been a much more productive thread if
some people totally stuck on the traditional stupid and sterile *RM is
good /OO is bad* (and vice versa) type of debate totally screwed it up.
They refuse discussion whether you bring sound arguments or not. Using
buzz words they dismiss as *nonsense* anything that can prove them
wrong...How practical...They are just close minded morons who can't
think on their own feet....
> However, I don't see much potential in memory controllers since the kind
> mentioned have no programming interface that a dbms implementer could
> get his or her hands on.
How the hell do you know as a certainty that this is not an
interresting track to follow? we are here to discuss theory aren't we.
As you said, maybe creating such programming interface may bring a
solution...
Dual Core architectures implement a closer relation between CPU and IO
physical adressing...As they are already programming interfaces to
pilot CPU threading and context switching, what makes you think this is
impossible?
> p
paul c
comments such as the TRM not being a physical layer. Also, I noticed
recently that the last of the LZW patents is about to expire. Not that
they're related but along with the latest jibe about physical matters,
it gets me to thinking about implementations again.
I can accept the assertion about TRM as being a kind of indirection as
long as I can envisage direct structures and algorithms for implementing
it. TRM's ideas may well go deeper than I can express but what stuck
with me about trying to implement it is that as far as deleting and
insert are concerned the nature of OS storage allocation, whether on
disk or in ram is such that lots of pointer chasing or re-allocation
seems to be needed, if one avoids a "row-image" mapping. (When I say
pointers, I don't necessarily mean the familiar 32 or 64 bit ones.)
In blunt terms, I couldn't see how a physical implementation of TRM
could avoid having two values for some equivalent of pointers for each
"row-column intersection", one to associate a value within a "row" or
"tuple" and another to place it within some ordering. Not counting the
values themselves, all those pointers seem to me to result in a physical
size that is probably similar to one that used, say, a btree index for
every column of a row-image table. Whether the indexes are sparse or
dense or whether they have shortcuts to avoid repeating identical values
seemed irrelevant as far as comparing a TRM implementation with say, a
so-called column-based store.
What I read about TRM seemed to echo my impression, if only because of
the two logical structures it gives.
At the level or disk or ram, it seems to me that for a db of
unpredictable size the usual fragmentation wastage will arise. (Also,
depending on the number of columns, insert and delete time could be
quite lengthy for an implementation that tries to minimize storage.)
Finally, I wonder whether anybody has thought of implanting an LZW or
other compression variation in conventional indexes.
Whether TRM is fundamentally a new idea or not doesn't seem to be a
question that its proponents are going to give us an answer for. If
somebody could show that at a physical level, it has no overriding
advantages, I think that would be useful as I suspect there are others
besides me for whom it would save time. Of course if somebody could
show the opposite, that might be even more useful.
p
Cimode
paul c wrote:
> Like some others here (as best as I can recall), I've puzzled over
> comments such as the TRM not being a physical layer.
Anybody who stated has not a clue about RM...What a stupid
comment...who advocated that? I certainly did'nt...
Also, I noticed
> recently that the last of the LZW patents is about to expire. Not that
> they're related but along with the latest jibe about physical matters,
> it gets me to thinking about implementations again.
>From reading the patents information and observation, I have not found
anything related to hardware issues and their impact on implementation.
Only algoryhtmics explanations about representation and operations
have been exposed to the public...
> I can accept the assertion about TRM as being a kind of indirection as
> long as I can envisage direct structures and algorithms for implementing
> it. TRM's ideas may well go deeper than I can express but what stuck
> with me about trying to implement it is that as far as deleting and
> insert are concerned the nature of OS storage allocation, whether on
> disk or in ram is such that lots of pointer chasing or re-allocation
> seems to be needed, if one avoids a "row-image" mapping. (When I say
> pointers, I don't necessarily mean the familiar 32 or 64 bit ones.)
The problem is much more complex then simple mapping. It's about
faitful physical representation of a multidimensional relvars when
limits are imposed by current computing scheme involving
> In blunt terms, I couldn't see how a physical implementation of TRM
> could avoid having two values for some equivalent of pointers for each
> "row-column intersection", one to associate a value within a "row" or
> "tuple" and another to place it within some ordering. Not counting the
> values themselves, all those pointers seem to me to result in a physical
> size that is probably similar to one that used, say, a btree index for
> every column of a row-image table.
That's my point...Anyway you turn it, physical implementation limit the
representation of a relvar...
Indexes are a secondary irrelevant issue. Building a better relational
DBMS supposes you just ignore that concept...
Whether the indexes are sparse or
> dense or whether they have shortcuts to avoid repeating identical values
> seemed irrelevant as far as comparing a TRM implementation with say, a
> so-called column-based store.
>
> What I read about TRM seemed to echo my impression, if only because of
> the two logical structures it gives.
>
> At the level or disk or ram, it seems to me that for a db of
> unpredictable size the usual fragmentation wastage will arise. (Also,
> depending on the number of columns, insert and delete time could be
> quite lengthy for an implementation that tries to minimize storage.)
>
> Finally, I wonder whether anybody has thought of implanting an LZW or
> other compression variation in conventional indexes
.
A true relational DBMS has not indexes. Just ignore them. You think
too much in function of the SQL implementation and not enough in
function of RM?
> Whether TRM is fundamentally a new idea or not doesn't seem to be a
> question that its proponents are going to give us an answer for. If
> somebody could show that at a physical level, it has no overriding
> advantages, I think that would be useful as I suspect there are others
> besides me for whom it would save time. Of course if somebody could
> show the opposite, that might be even more useful.
TRM has brought some interesting insights on programmatics of
representation but not sufficiently about physical architecture
prerequisites. He has not dealt to the relatonship between
programmatic handling of datum and its efficiency on computing
architecture (CPU to RAM to Disk). Maybe these should be reconsidered
first...
> p
paul c
> paul c wrote:
>> Cimode wrote:
>>> paul c wrote:
>>>> Cimode wrote:
>>>>> ...
>>>>>
>
> solution...
> Dual Core architectures implement a closer relation between CPU and IO
> physical adressing...As they are already programming interfaces to
> pilot CPU threading and context switching, what makes you think this is
> impossible?
Heh, heh, now I get it. You're talking about the sticky materials those
cpus are glued to their boards or heatsinks with!
While we're into the non-sequiturs, if you want to talk on a physical
issue that's becoming more and more of a problem, there's the advent of
huge L1/L2 cache because ram can't keep up with the latest cpus. I
don't think that's fundamental though, reminds me in a way of the little
windmill generators airlines have for when the main jets fail in mid-flight.
p
paul c
> ...
> TRM has brought some interesting insights on programmatics of
What are they?
p
J M Davitt
> paul c wrote:
>
>>Like some others here (as best as I can recall), I've puzzled over
>>comments such as the TRM not being a physical layer.
>
> Anybody who stated has not a clue about RM...What a stupid
> comment...who advocated that? I certainly did'nt...
>
> Also, I noticed
>
>>recently that the last of the LZW patents is about to expire. Not that
>>they're related but along with the latest jibe about physical matters,
>>it gets me to thinking about implementations again.
>
>>From reading the patents information and observation, I have not found
> anything related to hardware issues and their impact on implementation.
> Only algoryhtmics explanations about representation and operations
> have been exposed to the public...
Are you referring to the TRM patent or the LZW patent?
>>I can accept the assertion about TRM as being a kind of indirection as
>>long as I can envisage direct structures and algorithms for implementing
>>it. TRM's ideas may well go deeper than I can express but what stuck
>>with me about trying to implement it is that as far as deleting and
>>insert are concerned the nature of OS storage allocation, whether on
>>disk or in ram is such that lots of pointer chasing or re-allocation
>>seems to be needed, if one avoids a "row-image" mapping. (When I say
>>pointers, I don't necessarily mean the familiar 32 or 64 bit ones.)
>
> The problem is much more complex then simple mapping. It's about
> faitful physical representation of a multidimensional relvars when
> limits are imposed by current computing scheme involving
"...involving" what?
>>In blunt terms, I couldn't see how a physical implementation of TRM
>>could avoid having two values for some equivalent of pointers for each
>>"row-column intersection", one to associate a value within a "row" or
>>"tuple" and another to place it within some ordering. Not counting the
>>values themselves, all those pointers seem to me to result in a physical
>>size that is probably similar to one that used, say, a btree index for
>>every column of a row-image table.
>
> That's my point...Anyway you turn it, physical implementation limit the
> representation of a relvar...
> Indexes are a secondary irrelevant issue. Building a better relational
> DBMS supposes you just ignore that concept...
>
> Whether the indexes are sparse or
>
>>dense or whether they have shortcuts to avoid repeating identical values
>>seemed irrelevant as far as comparing a TRM implementation with say, a
>>so-called column-based store.
>>
>>What I read about TRM seemed to echo my impression, if only because of
>>the two logical structures it gives.
>>
>>At the level or disk or ram, it seems to me that for a db of
>>unpredictable size the usual fragmentation wastage will arise. (Also,
>>depending on the number of columns, insert and delete time could be
>>quite lengthy for an implementation that tries to minimize storage.)
>>
>>Finally, I wonder whether anybody has thought of implanting an LZW or
>>other compression variation in conventional indexes
>
> A true relational DBMS has not indexes. Just ignore them. You think
> too much in function of the SQL implementation and not enough in
> function of RM?
Who? paul? paul is thinking of SQL implementations?
>>Whether TRM is fundamentally a new idea or not doesn't seem to be a
>>question that its proponents are going to give us an answer for. If
>>somebody could show that at a physical level, it has no overriding
>>advantages, I think that would be useful as I suspect there are others
>>besides me for whom it would save time. Of course if somebody could
>>show the opposite, that might be even more useful.
>
> TRM has brought some interesting insights on programmatics of
> representation but not sufficiently about physical architecture
> prerequisites. He has not dealt to the relatonship between
> programmatic handling of datum and its efficiency on computing
> architecture (CPU to RAM to Disk). Maybe these should be reconsidered
> first...
Okay, I'll bite: what are "programmatics of representation?"
>
>>p
Cimode
paul c a écrit :
> Cimode wrote:
> > paul c wrote:
> >> Cimode wrote:
> >>> paul c wrote:
> >>>> Cimode wrote:
> >>>>> ...
> >>>>>
> >
> > As you said, maybe creating such programming interface may bring a
> > solution...
> > Dual Core architectures implement a closer relation between CPU and IO
> > physical adressing...As they are already programming interfaces to
> > pilot CPU threading and context switching, what makes you think this is
> > impossible?
> > ...
>
>
> Heh, heh, now I get it. You're talking about the sticky materials those
> cpus are glued to their boards or heatsinks with!
The media is not the issue. The problem is onto how
> While we're into the non-sequiturs, if you want to talk on a physical
> issue that's becoming more and more of a problem, there's the advent of
> huge L1/L2 cache because ram can't keep up with the latest cpus.
The basic premise of this thread was to suggest that physical issues
may restrict faithfull representation of relvars and asking the
question on whether OO mechanisms could help (maybe through the idea
you suggested of a closer programming interface controlling
representation through N-ary physical scheme)...If I am not mistaken a
non-sequiturs involve false premice. The premice has not been proven
wrong therefore your description is not adequate...
Besides, the fact that RAM has never been able to keep up with CPU is
not related to latest tendancies. Already in X86 architectures at most
30% of potential aws reached..
...I
> I don't think that's fundamental though, reminds me in a way of the little
> windmill generators airlines have for when the main jets fail in mid-flight.
The
Why don't you deepen your initial thought about programming interfaces
instead of using irrelevant analogies.;It's not about power, it's about
architecture...
> p