Re: Possible bridges between OO programming proponents and relational model

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Mon, 05 Jun 2006 00:58:50 GMT
Message-ID: <elLgg.17655$A26.409464_at_ursa-nb00s0.nbnet.nb.ca>


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.

> //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. Received on Mon Jun 05 2006 - 02:58:50 CEST

Original text of this message