Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

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

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 06 Jun 2006 18:05:46 GMT
Message-ID: <_tjhg.18430$A26.424258@ursa-nb00s0.nbnet.nb.ca>


Alfredo Novoa wrote:

> Robert Martin wrote:

Some people, who seem unable to recognize ignorant stupidity on their own, have criticized me for not explaining my reaction to Robert Martin's profound stupidity and ignorance as evidenced by the statements Alfredo quoted.

In the hopes that someone may actually learn from the effort, here goes:

>>>>The big problem with OO and RDB is that people try to make them
>>>>represent each other. RDB is about data structure an OO is about
>>>
>>>behavior structure.

> 

>>>No no no! RDB is about data management and OO is about application
>>>programming.

>
>>That's what I said. This shows profound ignorance of Thesauri.

Actually, Robert shows his profound ignorance of the manipulation, integrity and derivation functions of any dbms. Manipulation, integrity and derivation are behavior. A logical data model necessarily specifies both structure and behavior.

OO is an ad-hoc collection of features useful for creating large unpredictable state machines out of small predictable state machines. The idiot seems to think behavior can only refer to state transitions while failing to see the utility of manipulation and derivation for deriving a new state given an existing state and a transition.

>>>The DBMS must enforce all the business rules (data behavior). The OO
>>>applications must enforce the presentation and communication behavior.

> 

>>Nahhh. The DBMS must store the data, manage the queries, and enforce
>>some integrity rules. Business rules are in the domain of the
>>application. We don't want the business rules being done by the
>>database. What if we replace the database vendor? Must we rewrite all
>>the business rules?

Here Robert Martin shows an astonishing incapacity to comprehend relatively plain english. Business rules are in the domain of the business. Somehow the idiot cannot tell the difference between a business and an application.

Because business rules apply to the entire business and not just to a single application, one prefers to enforce and enact those rules centrally for the entire business. A good dbms serves this function extremely well in almost all cases.

Logical independence, the information principle and the very powerful transformation capabilities of even the worst dbms make changing dbms vendors relatively simple. Because constraints are ultimately written as well-formed formulae in some approximation of predicate logic, transforming from one syntax to another is generally simple and mechanical. One almost never has to rewrite all the business rules from scratch.

Further, while some untimely data may be retired or archived, the data needs of few businesses change in any revolutionary manner. On the other hand, applications and application programming languages are frequently abandoned at the end of some maintenance cycle or at the whim of some programmer. When businesses obscure their business rules in applications, they do indeed have to rewrite all of their business rules from scratch whenever they switch application programming languages because different programming languages often involve entirely different computational models.

Furthermore, businesses sometimes find themselves in the uncomfortable position more than a few companies found themselves in who approached the Y2K issue with active applications for which they could no longer find the source-code.

I am not sure who Robert Martin refers to when he uses "we" above but I assume he means himself and everyone else who is either too stupid or too ignorant or both to reason effectively.

>>>>The objects in the OO program should MANIPULATE the
>>>>data structures from the RDB.

> 

>>>Very wrong. The OO program should TRANSFORM the user input in orders
>>>for the DBMS.
> 

>>>The OO program is an interface between the users and the DBMS. A
>>>friendly substitute for the DBMS console.
> 

>>No, a DBMS is a bucket of bits with some low level rules to manage
>>those bits.

Here he equates predicate logic with a bucket of bits. Here he equates set algebra with a bucket of bits. He equates mathematics and logic with random bits. This not only shows his profound stupidity and profound ignorance, but it also shows his entirely anti-intellectual attitude. Not satisfied with his own ignorance and stupidity, he needs to encourage others to remain as stupid and as ignorant as he is.

That suggests to me that he is a predator who feeds off the ignorance of others.

A database management system provides a number of very high-level and important functions: manipulation, integrity, derivation, recovery, security, concurrency, etc. All of those functions are behavior.

   An OO application provides the beavior that the customer
>>wants to see. We can completely eliminate the DBMS and replace it with
>>another of an entirely different form (non Relational for example) and
>>still have all the business behavior we need.

Again, he demonstrates profound ignorance and stupidity. One cannot do as he claims unless one re-implements all of the functions of a dbms. While OO proponents often attempt to do this, they fail to re-implement most of the functions and what functions they do implement are generally incomplete and erroneous.

>>The people who sell databases have sold you, and the industry, a
>>misconception: that the database is the heart of the system. This is
>>flawed.

Were I prone to armchair psychology, I would label the above 'projection'. The idiot accuses others of doing exactly what he does: selling misconceptions. Just like any other snake-oil salesman, he sells ignorance.

Here, I think it suffices to point out that his only support for his ignorant assertion is ignorant assertion.

   The heart of the system is the application code. The database
>>is a detail to be decided at the last possible moment and kept in a
>>position so flexible that it can be swapped out for another at a whim.

Above, I have generally overlooked his sloppy use of precise terminology to focus on more important points that demonstrate his profound ignorance. Here I will point out that Mr. Martin cannot even tell the difference between 1) a database, which is a set of facts, 2) a database management system, which is a system of software and hardware for managing databases, 3) a logical data model, which is a formalism for representing and manipulating data, and 4) a logical schema, which is what one designs to represent specified information in a specified formalism.

If one were to take the last few of Mr. Martin's statements at face value, he would be castigating AC Nielsen, Dun & Bradstreet, Trade Services, Bloomfield, Lexis-Nexis and other vendors of databases for allegedly selling a flawed misconception. To make sense of his statements, one would have to conclude he never used a dbms in the first place choosing instead to access directly the raw streams provided by these vendors. And of course, his statements would not apply to any data derived from the processes of the business itself but only to databases sold by vendors.

> If the mentors are like this, I don't want to imagine the rest.

What I find most troubly about Mr. Martin's behavior is the active attempt to discourage others from learning preferring instead to keep his audience just as ignorant as he is.

All of the points I make in this post have been made several times already in this thread. Those who petulantly demanded I repeat these arguments here are no doubt just as ignorant and as stupid at Mr. Martin himself because they proved themselves incapable to recognize the same arguments when given elsewhere. Received on Tue Jun 06 2006 - 13:05:46 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US