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

Christian Brunschen wrote:

> In article <LUKfg.16278$A26.376787_at_ursa-nb00s0.nbnet.nb.ca>,
> Bob Badour <bbadour_at_pei.sympatico.ca> wrote:
>

>>Christian Brunschen wrote:
>>
>>
>>>LDAP is not usually considered 'obsolete'. For its specific purpose it 
>>>appears to be fairly well-liked and in widespread use.
>>
>>I agree that obsolete is a very poor choice of word. It implies 
>>unpopularity of something that might still be in good working order. In 
>>this case, the thing is very popular while not necessarily working all 
>>that well.

"Seems to work well" is not the same as "works well" especially without experience.

>>>The interface should indeed be between the application and a pluggable 
>>>service - but the database can be exactly such a pluggable service. SQL 
>>>itself is a shared, well-defined common interface that permits using many 
>>>different vendors' database implementationas as pluggable services.
>>>
>>>In the case of authenticating a user, when using LDAP as a back-end there 
>>>might be a pre-existing 'authenticate this user in this LDAP database' 
>>>operation available, which could be used to almost directly implement out 
>>>'wrapped' user authentication service; when using a SQL RDBMS as the 
>>>back-end, we might store a one-way-encrypted version of the password in a 
>>>column of the user table, and perform authentication with a 'select name, 
>>>password from user where name = foo and encrypted_password = xh54k' query.
>>
>>Or one might simply use the very powerful and transparent authentication 
>>and security features of the dbms itself. I see no reason to fantasize 
>>additional complexity.

With all due respect, to be a DBMS, a dbms must have very powerful and transparent authentication and security features--regardless of the logical data model upon which it is based. Security is, after all, one of the fundamental functions of a database management system.

[argument predicated on false axiom snipped]

>>>>There might be other examples there some data by techical reasons need
>>>>to be stored somewhere else but a SQL database, but that is still not
>>>>an argument for separating all SQL statements by default.
>>>
>>>The reason for separating SQL statements from the application code is the 
>>>same reason as for generally writing functions/procedures/methods.
>>
>>But I fail to see how abstractions separate anything from the 
>>application. The definitions of the functions/procedures/methods remain 
>>part of the application.

I understand the concepts of abstraction and information hiding. However, I have yet to see anyone put forward a decent argument for creating a layer in which to hide the higher-level abstractions from the lower-level abstractions. Usually, information hiding works in the other direction by hiding the lower-level details to keep them from getting in the way of human comprehension.

Relations, the relational algebra and the relational calculus are much higher-level abstractions than any in OO.

  And using a higher level of abstraction means that you are
> hiding unnecessary implementation details, which is also usually
> considered a good thing.

Your sentence would make sense if you were not arguing for a necessity to hide the higher-level abstractions from the lower-level computation models.

>>>... basically putting an SQL front-end on an LDAP database, in order to 
>>>be able to use SQL as a common database interface? That's certainly one 
>>>solution. My preferred solution is to define a higher-level interface that 
>>>is then implemented using whatever each database's most appropriate 
>>>interface is.
>>
>>How does one create a higher-level interface in a lower-level language? 

I have a problem with the part where the lower-level computational model suddenly becomes higher-level than the much higher-level abstration, ie. predicate logic, which you seek to hide.

>>Do you likewise recommend implementing higher-level interfaces to your 
>>C/C++/Java/OO-du-jour in assembler?

It certainly doesn't sound like it. I suggest in that case you are unable to recognize which tools are proper; even though, your heart might be in the right place.

, using the most appropriate
> level of abstraction,

Quite frankly, you are arguing directly against using the most appropriate level of abstraction. I am beginning to conclude you are ill-equipped to recognize that, though.

  keeping separate parts of the system separate (and
> potentially pluggable).

Define separate. Define pluggable. Explain how it makes sense to avoid using predicate logic for expressing logic or how it makes sense to avoid using a data management system for managing data.

[embedded application irrelevancies snipped]

>> The end result is essentially the same: There's a sihgle,
>>
>>>well-defined interface through which we can work with the data as 
>>>necessary from the point of view of the application.
>>
>>What makes it well-defined? 

Apparently, you use a radically different definition for 'well-defined' than the rest of the universe.

Predicate logic is well-defined. Set theory is well-defined. The relational algebra and calculus are well-defined. These are all formalisms that are well-defined both syntactically and semantically. They are the current culmination of a couple millenia of advances in mathematics and logic.

Some arbitrary rule of thumb used in conjuction with an ad-hoc collection of features for creating large unpredictable state machines is not nearly so well-defined.

I direct you once again to Dijkstra's comments on elixirs, impotence and illusion. While he wrote EWD 896 and 898 more than two decades ago, he could have just as easily been describing you today.

>>The relational model is well-defined 
>>equivalently as set algebra and predicate logic. What causes you to 
>>consider an ad-hoc collection of features for creating large complex 
>>state machines well-defined?

Instead of regurgitating meaningless jargon, why don't you answer the question I asked?

If one interprets your list as requiring syntactic and semantic definitions with the added requirement for some measure of elegance, you still have not established that the ad-hoc collection of features for creating large complex state machines meets those requirements. I suggest to you that OO is not clear at all, is not succinct relative to predicate logic or the RM, and is anything but precise.

OO offers nowhere near the functionality provided by either the relational algebra or the relational calculus in any manner useful or otherwise. Neither is it anywhere near as elegant as the RM nor does it provide anywhere near the same level of physical or logical independence.

By failing to meet the RM let alone surpass the RM on any relevant property, OO hasn't even made it into the game as far as I am concerned.

>>>>(I have done a similar solution while converting stored
>>>>procedures to Java. The client still thinks it is calling a stored
>>>>procedure in the database using "execute procedure abc()". But the ODBC
>>>>realized that this is not a database call and calls the appropiate java
>>>>method instead.)
>>>
>>>Cool. One could consider what you are doing as basically implementing an 
>>>RDBMS with an SQL interface, which just happens to delegate a lot of its 
>>>functionality to a second, pre-existing RDBMS with an SQL interface; not 
>>>entirely unlike using the Facade design pattern.
>>
>>So, I take it you consider expending considerable effort to re-invent 
>>existing services "cool" ? 

Okay, fair enough.

> Incidentally, the fact that you had to perform this 'interception'
> suggests that the interface that the client used didn't sufficiently
> insulate the client from changes to the service it was using.

I didn't have to do that, and in fact did not do that. It was another person's anecdote. I fail to see any valid basis to your argument here, though. The service changed and someone changed a low-level interface between two systems without affecting any of the higher-level code on either side.

How do you arrive at the conclusion that anything was insufficiently insulated?

>>Does "cool" justify the expense? Are you the 
>>one actually paying for "cool" or is that someone else?

Why did you use that single word? (No need to answer, you already did above.) Received on Fri Jun 02 2006 - 15:21:31 CEST