Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 31 May 2006 20:19:20 GMT
Message-ID: <cTmfg.15645$A26.364501_at_ursa-nb00s0.nbnet.nb.ca>


Robert Martin wrote:

> On 2006-05-31 10:53:23 -0500, Bob Badour <bbadour_at_pei.sympatico.ca> said:
>

>> Robert Martin wrote:
>> The decision to use SQL or Relational technology is NOT at the
>>
>>> core of the system.  But the structure of the data IS.  That 
>>> structure can, and should, be decided in a technolgy agnostic way for 
>>> as long as possible.
>>
>> And this is why I say that what you write is such ignorant tripe.

>
> Ah, back to the ad-hominems.

Hey, if you don't want people to point out that what you write is ignorant tripe, stop writing ignorant tripe.

>> A logical data model provides the structure, manipulation and 
>> integrity for a formal system. A good logical data model imposes no 
>> particular structure on the data as a whole while it does provide a 
>> structure in which to represent data. In fact, the structure of the 
>> data itself depends largely on one's point of view. One drastically 
>> alters the appearance of any graph by starting at a different location 
>> and traversing the edges in different directions.

>
> I'm with you so far.
>
>> As a logical data model, the relational model works very well

>
> Surely.
>
>>  while the available alternatives work very, very poorly by comparison.

>
> Certainly there are application domains where I would not hesitate to
> use RDBs. There are also application domains where I would not think of
> using them at all.

Some applications have no data management needs. Stating that one would never think of using a data management system for a system without data management needs is pointless.

   So for some application domains RDSBs work very
> poorly, and other mechanisms work much better.

What do you mean by "mechanism" in any case? Logical data models are formalisms and not mechanisms. It is nonsensical to compare "mechanisms" -- whatever you actually mean when you use the word -- with "formalisms". Idiot!

Here, you once again prove you are too stupid to comprehend simple english sentences. There are no data management problems for which the relational model works poorly. All of the other logical data models work poorly for data management.

Saying that some mechanism totally unrelated to data management works better for something totally unrelated to data management in response to a statement about data management and about formalism reeks of evasion. That kind of sophistry is worthless and indicates a lack of intellectual honesty.

You are stupid and ignorant, and your intellectual dishonesty accounts well for both. Your responses are pointless.

>> Even if one is forced to use a non-relational product, one would have 
>> to be a complete ignorant fool not to analyse the design relationally. 
>> It is, after all, the only formalism we have for data that is, itself, 
>> predicate logic and that treats all data symmetrically.

>
> I disagree.

That only further proves your stupidity and your ignorance.

   There are many data representations that can be useful and
> fruitful.

Nothing in the relational model precludes one from using graph theory or other formalisms in the design process. However, choosing a logical data model based on graphs is costly and dumb.

   The oft touted formalism of RDBs is fine; but does not
> preclude other mechanisms.

Here, once again, you demonstrate your profound ignorance and incapacity to comprehend written english. For any useful definition of mechanism, a mechanism is necessarily physical and related to how to achieve something. Physical independence provided by the relational model encourages the availability of a wide variety of mechanisms.

However, design analysis requires formalisms and not mechanisms. One prefers strongly to express design in terms of what and not how.

   For example, simple data structure
> representations are sometimes much more convenient and efficient than an
> RDB. As another example, consider your laptop. A lot of data is
> organized on that laptop using a directory and file structure rather
> than an RDB. This seems to work quite well as a general purpose
> organizing principle. There is no hue and cry for our filesystems to
> suddenly be RDBs.

That's only because the vast majority of computer users don't know what an RDBMS is. I would much prefer a file system organized using relations. I suggest Microsoft's recent focus on desktops and search indicates their usability studies have found problems with hierarchic directory structures that relations would go a long way toward solving.

Nothing in the drivel that you wrote above addresses my statements to which you expressed disagreement:

 >> Even if one is forced to use a non-relational product, one would have
 >> to be a complete ignorant fool not to analyse the design relationally.
 >> It is, after all, the only formalism we have for data that is, itself,
 >> predicate logic and that treats all data symmetrically.

Nowhere have you provided anything that even begins to suggest one would be wise to fail to analyse non-relational designs relationally. Neither have you provided an alternate formalism for data that is either symmetric or itself predicate logic.

>> As the only available symmetric data model, it is the only logical 
>> data model that even begins to allow one to consider data in a 
>> technology agnostic way.

>
> Again I disagree.

Again, informed intelligent people know why that is.

   I agree that RDBs DO allow a technology
> independence. However, they are not the only means to achieve this.
> Again, consider filesystems.

Are you suggesting that any given filesystem is technology agnostic?

   I am currently typing this on a macintosh
> that has a window open with MS windows running inside. The Windows
> filesystem can see into the mac file system with no trouble. Indeed,
> the virtual windows OS can see accross the network to another windows
> machine and see the files there.

So, a particular technology allows one to use that technology across a network and another piece of technology allows one to translate between two very similar yet different technologies. That doesn't make the technology agnostic to other technologies.

Filesystems seem to be quite
> technology agnostic.

You must obviously use definitions for technology and for agnostic that are either meaningless or very different from those used among computing professionals.

>> Given that, what you wrote above was self-contradictory while 
>> suggesting you live in some fantasy world where data may only ever 
>> appear in a single graph.

>
> You might be surprised at the world I live in.

No doubt. Plonk. Received on Wed May 31 2006 - 22:19:20 CEST

Original text of this message