f



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

Robert Martin wrote:

>>> 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.

>> 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?

>>> 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.  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.

>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.  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.

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


Regards
  Alfredo

0
5/29/2006 10:15:08 PM
comp.object 3218 articles. 1 followers. Post Follow

892 Replies
1804 Views

Similar Articles

[PageSpeed] 21

Alfredo Novoa wrote:

> Robert Martin wrote:
> 
> 
>>>>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.
> 
> 
>>>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?
> 
> 
>>>>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.  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.
> 
> 
>>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.  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.
> 
> If the mentors are like this, I don't want to imagine the rest.

Ugh. Alfredo, why did you have to ruin my evening? The ignorance and 
stupidity is astounding, isn't it?
0
bbadour (434)
5/29/2006 10:26:08 PM
Bob Badour wrote:
> Alfredo Novoa wrote:
>
> > If the mentors are like this, I don't want to imagine the rest.
>
> Ugh. Alfredo, why did you have to ruin my evening? The ignorance and
> stupidity is astounding, isn't it?

[removed comp.object]

Agreed.

"What if we replace the database vendor?" I've always found this
argument particularly ridiculous. What if we replace the application
programming language? I hear ruby's big this week.

I tried reading comp.object for a while, but it was too sweet for
my taste. Just pure, pure Kool-aid, mixed with heaping teaspoonsful
of self-congratulation.


Marshall

0
Marshall
5/29/2006 11:09:43 PM
IMHO these guys confuse problems " interaction between programms and
DBMS" with problems "objects and(or, vs., * etc. mark what you need)
relations". The first problem is technological and may be
methodological but the second one is only logical and mathematical. The
reason of this confising is that most of programs are OO and most of
DBMS are "relational"( i mean SQL) today and many persons do not try to
unerstand difference betwee these two kind of problems.

0
5/30/2006 6:21:13 AM
U-gene wrote:
> IMHO these guys confuse problems " interaction between programms and
> DBMS" with problems "objects and(or, vs., * etc. mark what you need)
> relations". The first problem is technological and may be
> methodological but the second one is only logical and mathematical. The
> reason of this confising is that most of programs are OO and most of
> DBMS are "relational"( i mean SQL) today and many persons do not try to
> unerstand difference betwee these two kind of problems.
> 

Nope. The problem is that some persons here are truly hard-core RDBMS
fanatics and and absolutely unable to understand that there's a life
outside RDBMS. RDBMS are really great for some things, and just suck for
some other things.

Both positions ('everything must go to the RDBMS' vs 'the RDBMS is just
a low-level storage') are wrong IMHO - as always, it's a matter of
choosing the right tool for the job.

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
5/30/2006 8:40:15 AM
> The problem is that some persons here are truly hard-core RDBMS
> fanatics and and absolutely unable to understand that there's a life
> outside RDBMS. RDBMS are really great for some things, and just suck for
> some other things.

Maybe the problem also is that some persons here are truly hard-core OO
fanatics and absolutely unable to understand that there's a life
outside OO. OO are really great for some things, and just suck for some
other things.

Fredrik Bertilsson
http://frebe.php0h.com

0
frebe73 (444)
5/30/2006 9:09:34 AM
Bob,

You had the "object" warning in the subject line O:-)

When managers want a new information system they usually contact with
an application programmer (without any database skills) trained by
supposed experts like this. No database expert is asked in the process.

I think that "mentors" like this should be debunked. They are making a
lot more harm than Dawn and the likes.


Regards
  Alfredo

0
alfredono (16)
5/30/2006 10:32:15 AM
"Alfredo Novoa" <alfredo_novoa@hotmail.com> wrote in message
news:1148940908.338233.159400@j73g2000cwa.googlegroups.com...

> >No, a DBMS is a bucket of bits with some low level rules to manage
> >those bits.  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.
>
> >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.  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.

I disagree completely with the above, which seems to have been written by
Robert Martin.

The heart of the system is the data.

For 20 years, I believed that the heart of the system was the application
code.  I wrote application code.  That's why I believed it.  But I've seen
enough to convince me otherwise in the last 17 years.

Not that I didn't say:  "the database".  What if we change database vendors?
Been there, done that.
What if we rewrite almost all the application code?  Been there,  done that.

What if we destroy all the data up to this point?  Time to update your
resume, everybody!


0
dcressey (35)
5/30/2006 10:54:52 AM
frebe73@gmail.com wrote:
>> The problem is that some persons here are truly hard-core RDBMS
>> fanatics and and absolutely unable to understand that there's a life
>> outside RDBMS. RDBMS are really great for some things, and just suck for
>> some other things.
> 
> Maybe the problem also is that some persons here are truly hard-core OO
> fanatics and absolutely unable to understand that there's a life
> outside OO. OO are really great for some things, and just suck for some
> other things.
> 
> Fredrik Bertilsson
> http://frebe.php0h.com
> 

Good points, but then, this is an OO-list.

There are probably great reasons to write emails to a list of OO-users, 
who want help with OO-problems, only to tell them that areas in which OO 
sucks ... but I can't really think of any immediately.

There are probably great reasons for writing to alt.hobby.sewing to tell 
them that sewing is a ridiculous solution to the problem of drilling for 
  oil in Alaska ... but I can't think of any immediate reasons for that, 
either.

It is healthy - in fact, it's crucial - to have nay-sayers on any list, 
to make sure we don't delude ourselves into thinking that OO solves all 
problems; topmind is a great poster for keeping OOers on their toes; but 
if you are going to nay-say, at least propose technical background, and 
don't just say, "OO is crap. Procedural 
programming/UML/assembler/whatever is just better, and if you can't see 
that, then you're stupid."

Having said all that, the newsgroups are public, so people will probably 
say whatever the hell they like; the main point is that some people, who 
have OO experience, offer solutions to OO problems posed by people 
having difficulty with OO - as long as that intercourse (matron!) isn't 
lost in the noise, then the this newsgroup has a purpose.

-- 
www.EdmundKirwan.com - Home of The Fractal Class Composition.

Download Fractality, free Java code analyzer:
www.EdmundKirwan.com/servlet/fractal/frac-page130.html
0
iamfractal (493)
5/30/2006 11:29:27 AM
bruno at modulix wrote:

> 
> Both positions ('everything must go to the RDBMS' vs 'the RDBMS is just
> a low-level storage') are wrong IMHO - as always, it's a matter of
> choosing the right tool for the job.
> 

How entirely wise.

"The right tool for the job."

Bruno at modulix, I salute you.

-- 
www.EdmundKirwan.com - Home of The Fractal Class Composition.

Download Fractality, free Java code analyzer:
www.EdmundKirwan.com/servlet/fractal/frac-page130.html
0
iamfractal (493)
5/30/2006 11:31:41 AM
Little point in preaching to the chuiar of course (how do you spell
that damn word ?).

Go tell this on an Otherwise Oriented forum, you'll get dawnbashed.

That said, application code is still highly important because it's
needed to fill all the holes that current dbms's still leave wide open
in the area of constraint enforcement.

Little true story : some OO proponent in a seminar (well, it was
actually "in front of an audience") declared that integrity enforcement
is the responsibility of the application, blahblahblah (he also
promoted meaningless ID's everywhere in the same breath).  I asked him
if he was actually aware that the first letter of the word IT stood for
"information".  His reply was : Yes, but the second stands for
"technology".

0
e.smout (9)
5/30/2006 11:31:53 AM
Alfredo Novoa wrote:
> Robert Martin wrote:
> >No, a DBMS is a bucket of bits with some low level rules to manage
> >those bits.  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.
>
> >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.  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.
>
> If the mentors are like this, I don't want to imagine the rest.

Considering the use of so many button-pushingly ludicrous statements
such as "a DBMS is a bucket of bits" and "swapped out for another at a
whim", do you not think perhaps Mr Martin was teasing (or goading) you?

0
andrewst1 (87)
5/30/2006 12:33:03 PM
On Tue, 30 May 2006 10:54:52 GMT, David Cressey wrote:

> "Alfredo Novoa" <alfredo_novoa@hotmail.com> wrote in message
> news:1148940908.338233.159400@j73g2000cwa.googlegroups.com...
> 
>>>No, a DBMS is a bucket of bits with some low level rules to manage
>>>those bits.  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.
>>
>>>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.  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.
> 
> I disagree completely with the above, which seems to have been written by
> Robert Martin.
> 
> The heart of the system is the data.

What is the data?

> For 20 years, I believed that the heart of the system was the application
> code.  I wrote application code.  That's why I believed it.  But I've seen
> enough to convince me otherwise in the last 17 years.
> 
> Not that I didn't say:  "the database".  What if we change database vendors?
> Been there, done that.
> What if we rewrite almost all the application code?  Been there,  done that.
> 
> What if we destroy all the data up to this point?  Time to update your
> resume, everybody!

But surely you can write your resume again. You can do it in MS-Word, or in
a Cuneiform script on clay tablets. No such thing as data, or more
generally information exist. There is a beautiful novel of great XX century
philosopher S. Lem. All data of humankind were put into a giant DB. The
first version of the main index had a size of a house. The secondary index
could be kept in a large room. The process of indexing continued until at
some point the index had become of one molecule size, so small, that the
chief librarian lost it. Humans returned to stone age. Where were the data?

Actually it is funny to see how relational approach intended to *abstract*
data away is turning to its antithesis in DB-minds.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
5/30/2006 12:45:00 PM
Robert Martin wrote:
>No, a DBMS is a bucket of bits with some low level rules to manage
>those bits.  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.
>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.  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.

No, a OO application is a bucket of bits with some low level rules to
manage
those bits.  An DBMS provides the beavior that the customer
wants to see.  We can completely eliminate the OO application and
replace it with
another of an entirely different form (non OO for example) and
still have all the business behavior we need.

The people who sell OO applications have sold you, and the industry, a
misconception: that the OO application is the heart of the system.
This is
flawed.  The heart of the system is the DBMS.  The OO application
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.

Regards,
Carlos M. Calvelo

0
c_jackal (9)
5/30/2006 12:51:15 PM
> Good points, but then, this is an OO-list.

The title of the original post is "Searching OO Associations with RDBMS
Persistence Models)". The subject is not completely inside the OO
domain and I think the discussion needs some people with RDBMS
competence too. Otherwise you have to encurage the original poster to
find another forum.

> don't just say, "OO is crap. Procedural programming/UML/assembler/whatever is just
> better, and if you can't see that, then you're stupid."
I didn't said that. I said: "OO are really great for some things..."

Fredrik Bertilsson
http://frebe.php0h.com

0
frebe73 (444)
5/30/2006 1:05:05 PM
frebe73@gmail.com wrote:
>> Good points, but then, this is an OO-list.
> 
> The title of the original post is "Searching OO Associations with RDBMS
> Persistence Models)". The subject is not completely inside the OO
> domain and I think the discussion needs some people with RDBMS
> competence too. Otherwise you have to encurage the original poster to
> find another forum.
> 
>> don't just say, "OO is crap. Procedural programming/UML/assembler/whatever is just
>> better, and if you can't see that, then you're stupid."
> I didn't said that. I said: "OO are really great for some things..."
> 
> Fredrik Bertilsson
> http://frebe.php0h.com
> 

Sorry, Fredrik, I didn't mean to suggest that you were one of the ones 
who says, "OO is crap, etc,."

Apologies ...

-- 
www.EdmundKirwan.com - Home of The Fractal Class Composition.

Download Fractality, free Java code analyzer:
www.EdmundKirwan.com/servlet/fractal/frac-page130.html
0
iamfractal (493)
5/30/2006 1:11:13 PM
CMCC wrote:
   The OO application
> 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.
> 

I consider myself, at present, an OOer (though a poor one), but I'd be 
deeply proud if I could write an application that was flexible enough to 
be swapped out for another at a whim (with no service degradation 
noticeable by customers, I presume you mean).

That would be a superb OO application indeed.

-- 
www.EdmundKirwan.com - Home of The Fractal Class Composition.

Download Fractality, free Java code analyzer:
www.EdmundKirwan.com/servlet/fractal/frac-page130.html
0
iamfractal (493)
5/30/2006 1:32:02 PM
Ed Kirwan wrote:
> CMCC wrote:
>   The OO application
> 
>> 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.
>>
> 
> I consider myself, at present, an OOer (though a poor one), but I'd be 
> deeply proud if I could write an application that was flexible enough to 
> be swapped out for another at a whim (with no service degradation 
> noticeable by customers, I presume you mean).
> 
> That would be a superb OO application indeed.
> 

If the customers didn't notice, what would be the point?
0
paul
5/30/2006 1:46:58 PM
Hello,

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 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.

0
cimode (135)
5/30/2006 1:52:49 PM
Lem is great man.

But that's my IMHO only. Index is piece of data what allows link some
values with physical structure which use to store these values. There
is no indexes in relation data model. There is no physical structue
there. Only values are used in any manipulation with values. So if we
have giant relational(!) DB we cannot make it smaller using described
"process of indexing". Bag analogy.

0
5/30/2006 2:03:36 PM
I've met a lot of mistakes in my previous message. Once again :)

.... Index is piece of data what allows link some values with physical
structure what are used to store these values. There is no indexes in
relation data model. There is no physical structure there. Only values
are used in any manipulation with values. So if we have giant
relational(!) DB we cannot make it smaller using described "process of
indexing" without data loss. Bad analogy.

0
5/30/2006 2:11:01 PM
Dmitry A. Kazakov wrote:

> On Tue, 30 May 2006 10:54:52 GMT, David Cressey wrote:
> 
> 
>>"Alfredo Novoa" <alfredo_novoa@hotmail.com> wrote in message
>>news:1148940908.338233.159400@j73g2000cwa.googlegroups.com...
>>
>>
>>>>No, a DBMS is a bucket of bits with some low level rules to manage
>>>>those bits.  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.
>>>
>>>>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.  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.
>>
>>I disagree completely with the above, which seems to have been written by
>>Robert Martin.
>>
>>The heart of the system is the data.
> 
> 
> What is the data?
> 
> 
>>For 20 years, I believed that the heart of the system was the application
>>code.  I wrote application code.  That's why I believed it.  But I've seen
>>enough to convince me otherwise in the last 17 years.
>>
>>Not that I didn't say:  "the database".  What if we change database vendors?
>>Been there, done that.
>>What if we rewrite almost all the application code?  Been there,  done that.
>>
>>What if we destroy all the data up to this point?  Time to update your
>>resume, everybody!
> 
> 
> But surely you can write your resume again. You can do it in MS-Word, or in
> a Cuneiform script on clay tablets. No such thing as data, or more
> generally information exist. There is a beautiful novel of great XX century
> philosopher S. Lem. All data of humankind were put into a giant DB. The
> first version of the main index had a size of a house. The secondary index
> could be kept in a large room. The process of indexing continued until at
> some point the index had become of one molecule size, so small, that the
> chief librarian lost it. Humans returned to stone age. Where were the data?
> 
> Actually it is funny to see how relational approach intended to *abstract*
> data away is turning to its antithesis in DB-minds.

Dmitry, you are an idiot. Plonk.
0
bbadour (434)
5/30/2006 2:14:09 PM
Tony Andrews wrote:

> Alfredo Novoa wrote:
> 
>>Robert Martin wrote:
>>
>>>No, a DBMS is a bucket of bits with some low level rules to manage
>>>those bits.  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.
>>
>>>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.  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.
>>
>>If the mentors are like this, I don't want to imagine the rest.
> 
> 
> Considering the use of so many button-pushingly ludicrous statements
> such as "a DBMS is a bucket of bits" and "swapped out for another at a
> whim", do you not think perhaps Mr Martin was teasing (or goading) you?

Are you suggesting that makes Mr. Marin any less of an idiot?
0
bbadour (434)
5/30/2006 2:15:40 PM
Tony wrote,

>Considering the use of so many button-pushingly ludicrous statements
>such as "a DBMS is a bucket of bits" and "swapped out for another at a
>whim", do you not think perhaps Mr Martin was teasing (or goading) you?

Tony, I would be delighted in that case, but I am afraid he was talking
seriously :(

I have seen many coders trying to put such ideas at practice in a very
literal way. I had to spend a considerable amount of time to stop these
ideas at my own job. The main argument of my opponents was: "everybody
does that".


Regards
  Alfredo

0
alfredono (16)
5/30/2006 2:19:30 PM
Ed Kirwan wrote:
> CMCC wrote:
>    The OO application
> > 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.
> >
>
> I consider myself, at present, an OOer (though a poor one), but I'd be
> deeply proud if I could write an application that was flexible enough to
> be swapped out for another at a whim (with no service degradation
> noticeable by customers, I presume you mean).
>
> That would be a superb OO application indeed.
>

No. That would mean you have a 'superb' database indeed; and
a system where subsystems *know* their responsibilities.
Read the reply of David Cressey.

Regards,
Carlos

0
c_jackal (9)
5/30/2006 2:52:47 PM
Bob Badour wrote:
> Tony Andrews wrote:
> > Considering the use of so many button-pushingly ludicrous statements
> > such as "a DBMS is a bucket of bits" and "swapped out for another at a
> > whim", do you not think perhaps Mr Martin was teasing (or goading) you?
>
> Are you suggesting that makes Mr. Marin any less of an idiot?

Maybe - if it means he doesn't actually believe something as
mind-bendingly stupid as it suggests he believes.  However, in that
case it was somewhat foolish of him not to signal that he was joking
via an emoticon or whatever, even if perhaps he thought it would be
obvious.  I haven't read enough of his posts to know for sure.

0
andrewst1 (87)
5/30/2006 4:30:36 PM
"Bob Badour" <bbadour@pei.sympatico.ca> wrote in message
news:RqYeg.15052$A26.352934@ursa-nb00s0.nbnet.nb.ca...
> Dmitry A. Kazakov wrote:

>
> > Actually it is funny to see how relational approach intended to
*abstract*
> > data away is turning to its antithesis in DB-minds.
>
> Dmitry, you are an idiot. Plonk.

Actually, I think Dmitri was one of the brothers Karamazov...  or is that
Kazakov?



0
dcressey (35)
5/30/2006 4:46:11 PM
frebe73@gmail.com wrote:
>>The problem is that some persons here are truly hard-core RDBMS
>>fanatics and and absolutely unable to understand that there's a life
>>outside RDBMS. RDBMS are really great for some things, and just suck for
>>some other things.
> 
> 
> Maybe the problem also is that some persons here are truly hard-core OO
> fanatics and absolutely unable to understand that there's a life
> outside OO. OO are really great for some things, and just suck for some
> other things.

This was implied by the rest of the post:
"""
Both positions ('everything must go to the RDBMS' vs 'the RDBMS is just
a low-level storage') are wrong IMHO - as always, it's a matter of
choosing the right tool for the job.
"""

Nowv FWIW the name of this group is comp.object, not comp.databases.

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
5/30/2006 5:04:05 PM
Ed wrote:

>There are probably great reasons to write emails to a list of OO-users,
>who want help with OO-problems, only to tell them that areas in which OO
>sucks ... but I can't really think of any immediately.

One reason is when a trickster is misleading people to use OO in an
area where it really sucks like data management.

A very strong reason, isn't it?


Regards
  Alfredo

0
5/30/2006 5:49:40 PM
Ed Kirwan wrote:
> CMCC wrote:
>    The OO application
> > 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.
> >
>
> I consider myself, at present, an OOer (though a poor one), but I'd be
> deeply proud if I could write an application that was flexible enough to
> be swapped out for another at a whim (with no service degradation
> noticeable by customers, I presume you mean).
>
> That would be a superb OO application indeed.
>
>

Maybe I have to explain. I try to give a hint... to think about
reasoning.
Which version did you like beter? That of Robert Martin or mine with
*only* 'OO application' and 'DBMS' exchanged?
Nobody complained about the first one. Nobody said:
"That would be a superb DBMS indeed, if it can be swapped out for
another at a whim"
What does that tell?

Regards,
Carlos

0
c_jackal (9)
5/30/2006 6:54:32 PM
David Cressey wrote:
> "Alfredo Novoa" <alfredo_novoa@hotmail.com> wrote in message
> news:1148940908.338233.159400@j73g2000cwa.googlegroups.com...
> 
>>> No, a DBMS is a bucket of bits with some low level rules to manage
>>> those bits.  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.
>>> 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.  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.
> 
> I disagree completely with the above, which seems to have been written by
> Robert Martin.
> 
> The heart of the system is the data.
> 

Wrong - the heart of the system is information, not data.


> For 20 years, I believed that the heart of the system was the application
> code.  I wrote application code.  That's why I believed it.  But I've seen
> enough to convince me otherwise in the last 17 years.
> 
> Not that I didn't say:  "the database".  What if we change database vendors?
> Been there, done that.
> What if we rewrite almost all the application code?  Been there,  done that.
> 
> What if we destroy all the data up to this point?  Time to update your
> resume, everybody!
> 
> 
0
news261 (167)
5/30/2006 7:09:02 PM
CMCC wrote:
> Ed Kirwan wrote:
> >
> > That would be a superb OO application indeed.
>
> Maybe I have to explain. I try to give a hint... to think about
> reasoning.
> Which version did you like beter? That of Robert Martin or mine with
> *only* 'OO application' and 'DBMS' exchanged?
> Nobody complained about the first one. Nobody said:
> "That would be a superb DBMS indeed, if it can be swapped out for
> another at a whim"
> What does that tell?

That the OO crowd is making demands of their DBMS that they
can't themselves meet with their OOP code.

Especially ironic that they would raise that point, given that
it would be a lot easier to switch DBMS vendors than it
would be to switch application languages.


Marshall

0
5/30/2006 7:11:58 PM
Andrew McDonagh wrote:
> >
> > The heart of the system is the data.
>
> Wrong - the heart of the system is information, not data.

I see. You have nothing useful to contribute, so you split
hairs over some terminological difference you imagine.


Marshall

0
5/30/2006 7:13:51 PM
Marshall wrote:
> Andrew McDonagh wrote:
>>> The heart of the system is the data.
>> Wrong - the heart of the system is information, not data.
> 
> I see. You have nothing useful to contribute, so you split
> hairs over some terminological difference you imagine.
> 
> 
> Marshall
> 

no - Data is (at least I hope) wildly known as being raw, Information is 
that Data interpreted in a meaningful way.

Do you need an example?
0
news261 (167)
5/30/2006 7:16:56 PM
Seems I got no success into getting some feedback on this input..I
thought extending the debate to a broader scope about possible
relationships between OO proponents and relational model would be
interresting...Maybe I should post another thread?

0
cimode (135)
5/30/2006 7:17:51 PM
"Marshall" <marshall.spight@gmail.com> wrote in 
news:1149016430.959323.162840@u72g2000cwu.googlegroups.com:

> Andrew McDonagh wrote:
>> >
>> > The heart of the system is the data.
>>
>> Wrong - the heart of the system is information, not data.
> 
> I see. You have nothing useful to contribute, so you split
> hairs over some terminological difference you imagine.

If you can't see that the difference between data and information really 
exists, then I suggest you are not terribly well placed to accuse anyone 
else of having nothing useful to contribute.

All the best,

John.
0
John
5/30/2006 7:21:01 PM
"Marshall" <marshall.spight@gmail.com> wrote in message
news:1149016430.959323.162840@u72g2000cwu.googlegroups.com...
> Andrew McDonagh wrote:
> > >
> > > The heart of the system is the data.
> >
> > Wrong - the heart of the system is information, not data.
>
> I see. You have nothing useful to contribute, so you split
> hairs over some terminological difference you imagine.
>
>
> Marshall
>

Marshall,

In another forum,  my tag line is:

"Information is what you want;  data is what you are given."

So I guess I have to accept his hairsplitting difference.

And I continue to assert:  the heart of the system is the data.

If Andrew wants to dismiss me as wrong,  so be it.




0
dcressey (35)
5/30/2006 7:30:07 PM
Create a new thread...Anybody interested in "Relationship between OO
Proponents and relational model" is welcome...

0
cimode (135)
5/30/2006 7:32:04 PM
On Tue, 30 May 2006 16:46:11 GMT, David Cressey wrote:

> "Bob Badour" <bbadour@pei.sympatico.ca> wrote in message
> news:RqYeg.15052$A26.352934@ursa-nb00s0.nbnet.nb.ca...
>> Dmitry A. Kazakov wrote:
> 
>>> Actually it is funny to see how relational approach intended to *abstract*
>>> data away is turning to its antithesis in DB-minds.
>>
>> Dmitry, you are an idiot. Plonk.
> 
> Actually, I think Dmitri was one of the brothers Karamazov...  or is that
> Kazakov?

(:-))

To continue this nice chain of associations: prince Mishkin's first name
was Leo ... and the axe, which Raskolnikov smashed his head with in Mexico,
reminds me the argumentation style of some people. (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
5/30/2006 7:32:30 PM
John D Salt wrote:
> "Marshall" <marshall.spight@gmail.com> wrote in
> news:1149016430.959323.162840@u72g2000cwu.googlegroups.com:
>
> > Andrew McDonagh wrote:
> >> >
> >> > The heart of the system is the data.
> >>
> >> Wrong - the heart of the system is information, not data.
> >
> > I see. You have nothing useful to contribute, so you split
> > hairs over some terminological difference you imagine.
>
> If you can't see that the difference between data and information really
> exists, then I suggest you are not terribly well placed to accuse anyone
> else of having nothing useful to contribute.

Well, there is a difference to the point that one is studied by
information theory, and the other by database theory. However, there is
close connection between the two. Database normalization is
minimization of information dependencies, and they could be treated
from information theory perspective (Mehmed Dalkilic: "information
entropy", etc). Anyway, what defintintions of information and data do
you youse, which makes the difference between them obvious?

0
5/30/2006 7:43:38 PM
Sorry the subject is "Possible bridges between OO programming
proponents and relational model"  .

0
cimode (135)
5/30/2006 8:22:47 PM
On 30 May 2006 06:52:49 -0700, Cimode wrote:

[I am not an OO proponent, I swear it on the keyboard! (:-))]

> 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).

Surely it does. Relational algebra describes the behavior of relational
container types.

> 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.

I don't think that anybody would seriously insist that RM lacks behavior.
People are arguing that it might be not the behavior needed for the case X.
Read "not" as "too low-level." It is not an intelligence expected, but a
higher abstraction level to handle complexity of the problem space at hand.
Machine registers also have a behavior...

> 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.

It is a vast theme on which there is no consensus. My personal view is that
subtyping = inheritance. Almost anybody from either side would disagree
with that...

> I am curious about your opinion about this matter as this is a new
> board for me.

Google for old comp.object discussions. It was beaten to death.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
5/30/2006 8:44:52 PM
Just wanted to give my vote for this post as the best argument ;)

Regarts,
    Joerg Simon

Ed Kirwan schrieb:
> frebe73@gmail.com wrote:
>>> The problem is that some persons here are truly hard-core RDBMS
>>> fanatics and and absolutely unable to understand that there's a life
>>> outside RDBMS. RDBMS are really great for some things, and just suck for
>>> some other things.
>>
>> Maybe the problem also is that some persons here are truly hard-core OO
>> fanatics and absolutely unable to understand that there's a life
>> outside OO. OO are really great for some things, and just suck for some
>> other things.
>>
>> Fredrik Bertilsson
>> http://frebe.php0h.com
>>
> 
> Good points, but then, this is an OO-list.
> 
> There are probably great reasons to write emails to a list of OO-users, 
> who want help with OO-problems, only to tell them that areas in which OO 
> sucks ... but I can't really think of any immediately.
> 
> There are probably great reasons for writing to alt.hobby.sewing to tell 
> them that sewing is a ridiculous solution to the problem of drilling for 
>  oil in Alaska ... but I can't think of any immediate reasons for that, 
> either.
> 
> It is healthy - in fact, it's crucial - to have nay-sayers on any list, 
> to make sure we don't delude ourselves into thinking that OO solves all 
> problems; topmind is a great poster for keeping OOers on their toes; but 
> if you are going to nay-say, at least propose technical background, and 
> don't just say, "OO is crap. Procedural 
> programming/UML/assembler/whatever is just better, and if you can't see 
> that, then you're stupid."
> 
> Having said all that, the newsgroups are public, so people will probably 
> say whatever the hell they like; the main point is that some people, who 
> have OO experience, offer solutions to OO problems posed by people 
> having difficulty with OO - as long as that intercourse (matron!) isn't 
> lost in the noise, then the this newsgroup has a purpose.
> 
0
j_simon (16)
5/30/2006 8:48:40 PM
Dmitry A. Kazakov wrote:
> On 30 May 2006 06:52:49 -0700, Cimode wrote:
> 
> [I am not an OO proponent, I swear it on the keyboard! (:-))]
> 

Snipped

> 
> It is a vast theme on which there is no consensus. My personal view is that
> subtyping = inheritance. Almost anybody from either side would disagree
> with that...
> 

oh good - now we can talk about subtype vs subclasses - they aren't the 
same - welcome to OO

:)
0
news261 (167)
5/30/2006 8:49:53 PM
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1icrhx7zxutcu$.ft684jpxktty.dlg@40tude.net...
> On Tue, 30 May 2006 16:46:11 GMT, David Cressey wrote:
>
> > "Bob Badour" <bbadour@pei.sympatico.ca> wrote in message
> > news:RqYeg.15052$A26.352934@ursa-nb00s0.nbnet.nb.ca...
> >> Dmitry A. Kazakov wrote:
> >
> >>> Actually it is funny to see how relational approach intended to
*abstract*
> >>> data away is turning to its antithesis in DB-minds.
> >>
> >> Dmitry, you are an idiot. Plonk.
> >
> > Actually, I think Dmitri was one of the brothers Karamazov...  or is
that
> > Kazakov?
>
> (:-))
>
> To continue this nice chain of associations: prince Mishkin's first name
> was Leo ... and the axe, which Raskolnikov smashed his head with in
Mexico,
> reminds me the argumentation style of some people. (:-))
>
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

I thought the guy who was axed in Mexico was Leon Trotsky...


0
dcressey (35)
5/30/2006 8:54:09 PM
John D Salt wrote:
> "Marshall" <marshall.spight@gmail.com> wrote in
> >
> > I see. You have nothing useful to contribute, so you split
> > hairs over some terminological difference you imagine.
>
> If you can't see that the difference between data and information really
> exists, then I suggest you are not terribly well placed to accuse anyone
> else of having nothing useful to contribute.

You would have a point if the two words had commonly
accepted definitions with important distinctions between
them. But they don't. Whether a difference "really exists"
hinges on the definitions used, and without reference to
specific definitions, the question has no meaning.

The fact that some group of people might make up
such definitions is perfectly reasonable. That they
would then assume that everyone else must know
and use their definitions in all contexts is not.

 
> All the best,

Thank you for the kind wishes.


Marshall

0
5/30/2006 8:56:55 PM
Marshall wrote:
> CMCC wrote:
> > Ed Kirwan wrote:
> > >
> > > That would be a superb OO application indeed.
> >
> > Maybe I have to explain. I try to give a hint... to think about
> > reasoning.
> > Which version did you like beter? That of Robert Martin or mine with
> > *only* 'OO application' and 'DBMS' exchanged?
> > Nobody complained about the first one. Nobody said:
> > "That would be a superb DBMS indeed, if it can be swapped out for
> > another at a whim"
> > What does that tell?
>
> That the OO crowd is making demands of their DBMS that they
> can't themselves meet with their OOP code.
>

I was only mimicking the reply of Ed Kirwan.
You did not react to that one. Or... did you agree with his?
(2nd level): What does that tell?

Lets not play games.
What Robert Martin seems to have written...  do you agree with that?

As an aside about other of your contributions:
Data is not Information, Information is not Knowledge, Knowledge is not
Wisdom.
(Maybe someone needs this one also: Data is not Wisdom)

Regards,
Carlos

0
c_jackal (9)
5/30/2006 8:59:34 PM
"Cimode" <cimode@hotmail.com> wrote in message
news:1149017607.537595.320820@i40g2000cwc.googlegroups.com...
> Sorry the subject is "Possible bridges between OO programming
> proponents and relational model"  .
>

OK,  back to the topic...

So far,  I've seen several attempts to project the world of objects onto the
world of (persistent) relations.  A table row
contains the "shadow" of an object,  projected onto the world of data.

This sounds like the easy way to go,  because the problem of producing a
decent DBMS based on the relational model has been extensively studied, and
according to some, actually implemented.

But I think it's upside down.

I think you have to solve the problem of defining a meaningful and useful
OODBMS without reference to the relational model.  You have to have the
things you would want in a DBMS,  like backups, transactions, concurrency
management,  etc.  You might even be able to acheive a certain measure of
physical data independence.  Logical data independence is probably too
ambitious a goal, without reference to the RM.

Once you have a decent OODBMS,  where you can maintain and share persistent
"value objects",  whatever those are,  now you've got a platform to build
on.  You define a persistent table as a certain class of persistent value
objects,  and define the methods that work on tables.  Hell, you can even
throw in indexes, if you're in the mood.

Now you've almost everything you need for an interface between an "object
world"  and a system of shared and persistent tables that represent data in
a form consistent with the RM.

I did say, "almost",  didn't I?

The one thing that's missing is a communications bridge between those who
understand the information in their own "object world",  but do not not how
to map that understanding to a system of tables,  and those who know how to
turn a system of table into information, but don't understand the object
world.     That's where I'm stumped.  I don't think you can formalize this
to the point where you can automate it.  But I can be proven wrong.









0
dcressey (35)
5/30/2006 9:08:14 PM
CMCC wrote:
> Marshall wrote:
>
> I was only mimicking the reply of Ed Kirwan.
> You did not react to that one. Or... did you agree with his?
> (2nd level): What does that tell?
>
> Lets not play games.

Agreed. However I already replied to a post of yours that
was a string of leading questions, and now I get another
string of leading questions. So I start to feel like we are,
in fact, playing games.


> What Robert Martin seems to have written...  do you agree with that?

I prefer to speak in terms of ideas rather than people. If you
wish to question my opinion on any particular idea, feel free.


> As an aside about other of your contributions:
> Data is not Information, Information is not Knowledge, Knowledge is not
> Wisdom.
> (Maybe someone needs this one also: Data is not Wisdom)

How about "Aphorisms are not Helpful."

(Imitation is the flattest form of sincerity.)


Marshall

0
5/30/2006 9:15:57 PM
Tony Andrews wrote:

> Bob Badour wrote:
> 
>>Tony Andrews wrote:
>>
>>>Considering the use of so many button-pushingly ludicrous statements
>>>such as "a DBMS is a bucket of bits" and "swapped out for another at a
>>>whim", do you not think perhaps Mr Martin was teasing (or goading) you?
>>
>>Are you suggesting that makes Mr. Marin any less of an idiot?
> 
> Maybe - if it means he doesn't actually believe something as
> mind-bendingly stupid as it suggests he believes.  However, in that
> case it was somewhat foolish of him not to signal that he was joking
> via an emoticon or whatever, even if perhaps he thought it would be
> obvious.  I haven't read enough of his posts to know for sure.

So, in your view it is not idiotic to post something mind-bendingly 
stupid as long as one doesn't believe what one posts? What is your word 
for it? Mischievous? I would call it idiotic. A mischievous idiot is 
still an idiot.
0
bbadour (434)
5/30/2006 9:36:38 PM
Andrew McDonagh wrote:

> Marshall wrote:
> 
>> Andrew McDonagh wrote:
>>
>>>> The heart of the system is the data.
>>>
>>> Wrong - the heart of the system is information, not data.
>>
>>
>> I see. You have nothing useful to contribute, so you split
>> hairs over some terminological difference you imagine.
>>
>>
>> Marshall
>>
> 
> no - Data is (at least I hope) wildly known as being raw, Information is 
> that Data interpreted in a meaningful way.
> 
> Do you need an example?

Andrew, that definition is a fad among marketers and incompetent 
managers. Data is the subset of information represented suitably for 
machine processing, which is a standard definition you can find from 
ISO. It is probably the single most fundamental and important definition 
in computing science.

Your ignorance of it and your sheeplike acceptance of nonsense show how 
immature and regressive our field is right now. I suggest you try to 
spend less time reading fashion magazines and more time learning the 
fundamentals of your craft.
0
bbadour (434)
5/30/2006 9:44:36 PM
Bob Badour wrote:
> Andrew McDonagh wrote:
> 
>> Marshall wrote:
>>
>>> Andrew McDonagh wrote:
>>>
>>>>> The heart of the system is the data.
>>>>
>>>> Wrong - the heart of the system is information, not data.
>>>
>>>
>>> I see. You have nothing useful to contribute, so you split
>>> hairs over some terminological difference you imagine.
>>>
>>>
>>> Marshall
>>>
>>
>> no - Data is (at least I hope) wildly known as being raw, Information 
>> is that Data interpreted in a meaningful way.
>>
>> Do you need an example?
> 
> Andrew, that definition is a fad among marketers and incompetent 
> managers. Data is the subset of information represented suitably for 
> machine processing, which is a standard definition you can find from 
> ISO. It is probably the single most fundamental and important definition 
> in computing science.
> 
> Your ignorance of it and your sheeplike acceptance of nonsense show how 
> immature and regressive our field is right now. I suggest you try to 
> spend less time reading fashion magazines and more time learning the 
> fundamentals of your craft.

ouch!

(Andrew shakes his head an continues flicking through DBMS Weekly)
0
news261 (167)
5/30/2006 10:01:55 PM
Alfredo Novoa wrote:
> Robert Martin wrote:
> 
> 
>>>>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.
> 
> 
>>>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?
> 
> 
>>>>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.  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.
> 
> 
>>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.  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.
> 
> 
> If the mentors are like this, I don't want to imagine the rest.
> 
> 
> Regards
>   Alfredo
> 

Hm, I take it you're not a big fan of the Active Record pattern?

Joe
0
joe.vandyk (160)
5/30/2006 10:04:05 PM
Marshall wrote:
> Agreed. However I already replied to a post of yours that
> was a string of leading questions, and now I get another
> string of leading questions. So I start to feel like we are,
> in fact, playing games.

Agreed. But then again... your reply was not in line with my
question (or at least what I meant with it).
So I explain and ask again. I've got no answer yet.
Maybe I am not being understood.

>
>
> > What Robert Martin seems to have written...  do you agree with that?
>
> I prefer to speak in terms of ideas rather than people. If you
> wish to question my opinion on any particular idea, feel free.

I speak in terms of what he *seems to have written*. Somehow I have
to refer to what it is I am talking about! And that is the subject of
this thead.

>
> How about "Aphorisms are not Helpful."
>
> (Imitation is the flattest form of sincerity.)
> 

Fair enough!

Regards,
Carlos

0
c_jackal (9)
5/30/2006 10:10:47 PM
Andrew McDonagh wrote:
>
> no - Data is (at least I hope) wildly known as being raw, Information is
> that Data interpreted in a meaningful way.

As far as it being widely known, I would not agree. The two
words are virtually synonymous in common usage.

http://dictionary.reference.com/search?q=information
  information: "A collection of ... data"

http://dictionary.reference.com/search?q=data
  data: "factual information"

That there are communities out there who use the two
words in such a way as to have different connotations,
I am aware. I do not see that they gain anything by
doing so, and I do see how they lose, in that they
then assume everyone else will have the same
connotations.

In any event, David's point was clearly about "information"
according to your definitions, so the introduction of the
data/information split was superfluous.


> Do you need an example?

No, but thank you.


Marshall

0
5/30/2006 10:11:05 PM
Cimode wrote:

> Hello,
> 
> 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 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.

Cimode, the above seems like a rather broad overview of OO and the RM. I 
am not sure what you are seeking an opinion about. As a general rule 
online, the more specific the question the better then answers.

The relational model is symbolic logic.

OO is a low-level mechanism for creating large unpredictable state 
machines out of smaller predictable state machines. OO is all about 
managing variables.

After OO was created, folks noted that it has some utility for 
abstraction and reuse. However, the RM is a much better model for 
abstraction, has a more sound foundation, and provides more effective reuse.
0
bbadour (434)
5/30/2006 10:12:13 PM
Andrew McDonagh wrote:

> Bob Badour wrote:
> 
>> Andrew McDonagh wrote:
>>
>>> Marshall wrote:
>>>
>>>> Andrew McDonagh wrote:
>>>>
>>>>>> The heart of the system is the data.
>>>>>
>>>>>
>>>>> Wrong - the heart of the system is information, not data.
>>>>
>>>>
>>>>
>>>> I see. You have nothing useful to contribute, so you split
>>>> hairs over some terminological difference you imagine.
>>>>
>>>>
>>>> Marshall
>>>>
>>>
>>> no - Data is (at least I hope) wildly known as being raw, Information 
>>> is that Data interpreted in a meaningful way.
>>>
>>> Do you need an example?
>>
>>
>> Andrew, that definition is a fad among marketers and incompetent 
>> managers. Data is the subset of information represented suitably for 
>> machine processing, which is a standard definition you can find from 
>> ISO. It is probably the single most fundamental and important 
>> definition in computing science.
>>
>> Your ignorance of it and your sheeplike acceptance of nonsense show 
>> how immature and regressive our field is right now. I suggest you try 
>> to spend less time reading fashion magazines and more time learning 
>> the fundamentals of your craft.
> 
> ouch!
> 
> (Andrew shakes his head an continues flicking through DBMS Weekly)

I reiterate: I suggest you try to spend less time reading fashion 
magazines and more time learning the fundamentals of your craft.
0
bbadour (434)
5/30/2006 10:23:46 PM
Joe Van Dyk wrote:

> Alfredo Novoa wrote:
> 
>> Robert Martin wrote:
>>
>>>>> 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.
>>
>>>> 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?
>>
>>>>> 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.  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.
>>
>>> 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.  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.
>>
>> If the mentors are like this, I don't want to imagine the rest.
>>
>> Regards
>>   Alfredo
> 
> Hm, I take it you're not a big fan of the Active Record pattern?

Only a complete idiot would be. "Let's take something with the full 
power of predicate logic and leave it with, um, restriction. Yeah, 
that'll bring it down to the level we want!"
0
bbadour (434)
5/30/2006 10:31:10 PM
Bob Badour wrote:
> Andrew McDonagh wrote:
> >
> > (Andrew shakes his head an continues flicking through DBMS Weekly)
>
> I reiterate: I suggest you try to spend less time reading fashion
> magazines [...]

Bob, is DBMS Weekly anything like Entertainment Weekly?


Marshall

0
5/30/2006 10:35:07 PM
Marshall wrote:

> Bob Badour wrote:
> 
>>Andrew McDonagh wrote:
>>
>>>(Andrew shakes his head an continues flicking through DBMS Weekly)
>>
>>I reiterate: I suggest you try to spend less time reading fashion
>>magazines [...]
> 
> Bob, is DBMS Weekly anything like Entertainment Weekly?

If you ask me, it's just a made-up name. However, magazines are all the 
same. Entertainment Weekly, DBMS Magazine, Variety, People, Weekly World 
News -- all the same.

They entertain and they communicate jargon for people to use to signal 
they are 'in the know'. Some people are masters at inserting meaningless 
gibberish into a conversation to impress others.

If one cannot dazzle 'em with brilliance....
0
bbadour (434)
5/30/2006 10:42:51 PM
Marshall wrote:
> Bob Badour wrote:
>> Andrew McDonagh wrote:
>>> (Andrew shakes his head an continues flicking through DBMS Weekly)
>> I reiterate: I suggest you try to spend less time reading fashion
>> magazines [...]
> 
> Bob, is DBMS Weekly anything like Entertainment Weekly?
> 
> 
> Marshall
> 

Its more like those cheap glossy 'celeb' weekly mags we get in the UK, 
only instead of gossip about J-Lo, Brad, etc we have gossip about an 
Oracle instance being seen coming out  of mySQL room late at night.

Its very good!
0
news261 (167)
5/30/2006 10:44:15 PM
Andrew McDonagh wrote:
> Marshall wrote:
>> Bob Badour wrote:
>>> Andrew McDonagh wrote:
>>>> (Andrew shakes his head an continues flicking through DBMS Weekly)
>>> I reiterate: I suggest you try to spend less time reading fashion
>>> magazines [...]
>>
>> Bob, is DBMS Weekly anything like Entertainment Weekly?
>>
>>
>> Marshall
>>
> 
> Its more like those cheap glossy 'celeb' weekly mags we get in the UK, 
> only instead of gossip about J-Lo, Brad, etc we have gossip about an 
> Oracle instance being seen coming out  of mySQL room late at night.
> 
> Its very good!

ok, I gotta stop this - its getting way too surreal...

(Note I have no idea if there is a mag called RDBMS weekly)
0
news261 (167)
5/30/2006 10:45:27 PM
CMCC wrote:
> Marshall wrote:
>
> I speak in terms of what he *seems to have written*. Somehow I have
> to refer to what it is I am talking about! And that is the subject of
> this thead.

Grrrr. Okay, fine; I'll do the work. In the future if you have a
question
for me, it will be necessary to ask me the full actual question, and
not refer ambiguously to things written elsewhere.

[scanning back through the thread ...]

Okay, maybe you are asking about this:

>No, a DBMS is a bucket of bits with some low level rules to manage
>those bits.  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.
>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.  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.

There are many different contexts in which software is developed.
I will speak relative to enterprise software, which is where DBMS
software is often found. In that context, the above quoted
paragraph is pure, unadulterated garbage. It is not simply
valueless; it is actively harmful. The writer furthermore
demonstrates that he completely lacks any understanding
of what the field of data management is, or what it is for,
or why it is useful.

The reason why you see crap like this is because it is being
written by application developers. Application developers are
great at writing applications, but once they have success in
that one area, they overgeneralize and begin to believe that
their techniques are the correct techniques to apply to every
software development area. However this represents a
multi-decade regression in the field of data management.

Data management in the 1960s lacked any understanding
of the issues that the field has today. And if the application
programmers have their way, and the existing field of
data management is discarded, those same application
programmers will face all the same problems that the
programmers of the 1960s did, over again. And over
the decades, they'll build systems that tackle questions
like integrity enforcement, ad hoc queries, transaction
management, etc. Slowly, they will reinvent the field.

And, if they do so, it would be poetic justice if the
programmers being born today trash all their work
in favor of some new fad.


Marshall

0
5/30/2006 10:54:53 PM
Bruno wrote:

>Alfredo, in case you wouldn't know this, there are a lot of applications
>that have *nothing* to do with a RDBMS.

Of course, but obviously, we were not talking about them.

>The "rest" just do it's job: writing applications - with a RDBMS when
>it's the right tool, without when it's not. Thank you, and good night.

This is not true nor enough. Good night Bruno.

0
5/31/2006 12:11:48 AM
Indeed, it is a very stupid way to lose almost all the power a DBMS
offers.

0
5/31/2006 12:56:34 AM
David Cressey a �crit :
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:1icrhx7zxutcu$.ft684jpxktty.dlg@40tude.net...
> 
>>On Tue, 30 May 2006 16:46:11 GMT, David Cressey wrote:
>>
(snip)
>>>Actually, I think Dmitri was one of the brothers Karamazov...  or is
> 
> that
> 
>>>Kazakov?
>>
>>(:-))
>>
>>To continue this nice chain of associations: prince Mishkin's first name
>>was Leo ... and the axe, which Raskolnikov smashed his head with in
> 
> Mexico,
> 
>>reminds me the argumentation style of some people. (:-))
>>
> 
> I thought the guy who was axed in Mexico was Leon Trotsky...
> 

Wasn't that an ice-pick ?

Well, at least this sterile troll^Minstructive discussion starts to be 
of some interest.

0
5/31/2006 2:24:30 AM
Alfredo Novoa a �crit :
> Robert Martin wrote:
> 
(snip)
> 
>>>>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.

Alfredo, in case you wouldn't know this, there are a lot of applications 
that have *nothing* to do with a RDBMS.

> 
> If the mentors are like this, I don't want to imagine the rest.
> 
The "rest" just do it's job: writing applications - with a RDBMS when 
it's the right tool, without when it's not. Thank you, and good night.
0
5/31/2006 2:35:16 AM
On Tue, 30 May 2006 21:49:53 +0100, Andrew McDonagh wrote:

> Dmitry A. Kazakov wrote:

>> It is a vast theme on which there is no consensus. My personal view is that
>> subtyping = inheritance. Almost anybody from either side would disagree
>> with that...
> 
> oh good - now we can talk about subtype vs subclasses - they aren't the 
> same - welcome to OO
> 
> :)

Not this time, please! (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
5/31/2006 8:00:34 AM
On Wed, 31 May 2006 04:24:30 +0200, Bruno Desthuilliers wrote:

> David Cressey a �crit :
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:1icrhx7zxutcu$.ft684jpxktty.dlg@40tude.net...
>> 
>>>On Tue, 30 May 2006 16:46:11 GMT, David Cressey wrote:
>>>
> (snip)
>>>>Actually, I think Dmitri was one of the brothers Karamazov...  or is
>> 
>> that
>> 
>>>>Kazakov?
>>>
>>>(:-))
>>>
>>>To continue this nice chain of associations: prince Mishkin's first name
>>>was Leo ... and the axe, which Raskolnikov smashed his head with in
>> 
>> Mexico,
>> 
>>>reminds me the argumentation style of some people. (:-))
>>>
>> 
>> I thought the guy who was axed in Mexico was Leon Trotsky...
>> 
> Wasn't that an ice-pick ?
> 
> Well, at least this sterile troll^Minstructive discussion starts to be 
> of some interest.

OK, to close this off-topic, I'll decipher it a bit:

"The idiot" is a work by Dostoevsky, the main character there is prince Leo
Mishkin.

"The Brothers Karamazov" is also by Dostoevsky. One of the brothers is
Mitya. This name is a short form of the first name Dmitry (Russian variant
of Greek name Demetrios).

"Crime and Punishment" is again by him, there Raskolnikov kills an old lady
(money-lender) with an axe, in the course of a philosophical dispute about
the *relation* between means and goals.

Leo Trotsky, well you already heard that story.

-------------
Though I doubt that Bob Badour really meant that "idiot".

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
5/31/2006 8:29:20 AM
"Bruno Desthuilliers" <bdesth.quelquechose@free.quelquepart.fr> wrote in
message news:447cd16c$0$24912$626a54ce@news.free.fr...
> Alfredo Novoa a �crit :
> > Robert Martin wrote:
> >
> (snip)
> >
> >>>>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.
>
> Alfredo, in case you wouldn't know this, there are a lot of applications
> that have *nothing* to do with a RDBMS.
>
> >
> > If the mentors are like this, I don't want to imagine the rest.
> >
> The "rest" just do it's job: writing applications - with a RDBMS when
> it's the right tool, without when it's not. Thank you, and good night.

PMFJI.

I am sure that Alfredo knows that there are a large number of applications
that have nothing to do with an RDMS.  I'm sure I do.  I can't speak to
comp.object.  Over here in comp.databases.theory  we tend to put more focus
on applications that do interact with a database, because databases are our
subject matter.

I have to disagree with your summary,  at least  as it has played out in
practice.

There are a vast number of applications out there that should not have used
an RDBMS, but did.  (As in,  "all the smart people are using Oracle, so
let's use Oracle")  (That raises a discussion that has been beaten to death
multiple times in c.d.t.,  namely, that Oracle RDBMS is not an RDBMS.)

There are even a half vast number of applications that should have used a
DBMS to manage the persistent and shareable data, but instead used some kind
of dressed up file system,  and provide external access to data only through
some gawd awful and very obscure API.

To the extent that application data architects use an RDBMS when apropriate,
and not use it when it's not the right tool,  hurrah!  But I think we should
all recognize the high incidence of unfortunate decisions in this regard.




0
dcressey (35)
5/31/2006 10:34:26 AM
On 2006-05-29 17:15:08 -0500, "Alfredo Novoa" <alfredo_novoa@hotmail.com> said:
> 
> If the mentors are like this, I don't want to imagine the rest.

Excellent ad-hominem argument.  Very well done!  Abandon substantive 
argument all ye who enter this debate.  Concentrate on denegrating the 
man, not the argument!

-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 12:34:52 PM
On 2006-05-30 05:32:15 -0500, "Alfredo" <alfredono@gmail.com> said:

> Bob,
> 
> You had the "object" warning in the subject line O:-)
> 
> When managers want a new information system they usually contact with
> an application programmer (without any database skills) trained by
> supposed experts like this. No database expert is asked in the process.
> 
> I think that "mentors" like this should be debunked. They are making a
> lot more harm than Dawn and the likes.


This begins to approach a substantive argument, so I'll address it with 
substance and ignore the obligatory ad-hominem cowardice.

There is a difference between data modeling and databases.  Data 
modeling is an important discipline that must be considered for every 
application.  A good data model is a critical part of a good system 
architecture and, along with the partitioning of behavior, is close to 
the core value of the system.

A DBMS is a technical detail.  Decisions about it should be deferred as 
long as possible. The decision to use Oracle is NOT at the core of the 
system.  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.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 12:40:23 PM
Bob Badour wrote:
> So, in your view it is not idiotic to post something mind-bendingly
> stupid as long as one doesn't believe what one posts? What is your word
> for it? Mischievous? I would call it idiotic. A mischievous idiot is
> still an idiot.

Never mind.  I have read more of his posts, including where he says
"Sometimes the DATA is the heart of the system, but the storage
mechanisms is always a detail."

So he thinks of a DBMS as a "storage mechanism".

I agree with you fully.

0
andrewst1 (87)
5/31/2006 12:41:26 PM
On 2006-05-30 03:40:15 -0500, bruno at modulix <onurb@xiludom.gro> said:

> The problem is that some persons here are truly hard-core RDBMS
> fanatics and and absolutely unable to understand that there's a life
> outside RDBMS. RDBMS are really great for some things, and just suck for
> some other things.

More importantly RDBMSs are mechanisms that can be abstracted, and can 
therefore be dissociated from the application programs through an 
abstract interface.

> Both positions ('everything must go to the RDBMS' vs 'the RDBMS is just
> a low-level storage') are wrong IMHO - as always, it's a matter of
> choosing the right tool for the job.

It is always a matter of choosing the right tool for the job.  And 
that's the point.  A DBMS is a tool, not an overarching philosophy, nor 
the core of the system design.  A DBMS is a *mechanism* that can be 
used to *implement* certain elements of the system design.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 12:44:43 PM
On 2006-05-30 04:09:34 -0500, frebe73@gmail.com said:

>> The problem is that some persons here are truly hard-core RDBMS
>> fanatics and and absolutely unable to understand that there's a life
>> outside RDBMS. RDBMS are really great for some things, and just suck for
>> some other things.
> 
> Maybe the problem also is that some persons here are truly hard-core OO
> fanatics and absolutely unable to understand that there's a life
> outside OO. OO are really great for some things, and just suck for some
> other things.

I won't argue that OO has not been over-hyped.  Certainly it has.  
However, the principles of OO design are really just principles of good 
software design.  OO langauges simply gives us some good tools to help 
us managine coupling and cohesion better.

I have certainly found systems that should NEVER use an RDBMS.  But I 
have never found a system that could not benefit from a good OO 
language.

A good OO designer is not a fanatic about OO, S/he is a disciplined 
software designer that is able to use the tools of OO.

A good software designer can use both OO and RDB tools as, and when, 
needed.  However, RDB tools are mechanisms that can be deferred both in 
time and space to be considered later and partitioned into a small 
segment of the code.  OO tools are used throughout the design and 
implementation process and cannot be deferred either in time or space.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 12:48:49 PM
On 2006-05-30 12:49:40 -0500, "Alfredo Novoa" <alfredo_novoa@hotmail.com> said:

> Ed wrote:
> 
>> There are probably great reasons to write emails to a list of OO-users,
>> who want help with OO-problems, only to tell them that areas in which OO
>> sucks ... but I can't really think of any immediately.
> 
> One reason is when a trickster is misleading people to use OO in an
> area where it really sucks like data management.
> 
> A very strong reason, isn't it?

No, because the use of the term "trickster" makes the assumption that 
YOUR knowledge is perfect.  You assume that you KNOW that I am a 
trickster, and that my position cannot possibly be responsible or valid.

I am not trying to mislead anyone, Alfredo.  I am stating my opinions 
on a matter of deep interest to this group.  You may disagree with 
those opinions; and indeed, I welcome a spirited debate based on honest 
disagreement.  But I won't tolerate the arrogance of the ad-homimen 
attacks.  They are cowardly and arrogant.

-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 12:57:39 PM
> A DBMS is a tool, not an overarching philosophy, nor
> the core of the system design.  A DBMS is a *mechanism* that can be
> used to *implement* certain elements of the system design.

A DBMS is a tool. But the relational model is an overarching
philosophy.

Fredrik Bertilsson
http://frebe.php0h.com

0
frebe73 (444)
5/31/2006 1:04:41 PM
> I have certainly found systems that should NEVER use an RDBMS.  But I
> have never found a system that could not benefit from a good OO
> language.

But there are many (enterprise) applications there OOAD is not
suitable. Some OO languages (such as java) has disadvantages because
they don't allow first-order functions and function pointers.

> A good software designer can use both OO and RDB tools as, and when,
> needed.  However, RDB tools are mechanisms that can be deferred both in
> time and space to be considered later and partitioned into a small
> segment of the code.  OO tools are used throughout the design and
> implementation process and cannot be deferred either in time or space.

Why can't OO tools be deferred both in  time and space to be considered
later and partitioned into a small segment of the code?

Fredrik Bertilsson
http://frebe.php0h.com

0
frebe73 (444)
5/31/2006 1:10:16 PM
On 2006-05-30 06:31:41 -0500, Ed Kirwan <iamfractal@hotmail.com> said:

> bruno at modulix wrote:
> 
>> 
>> Both positions ('everything must go to the RDBMS' vs 'the RDBMS is just
>> a low-level storage') are wrong IMHO - as always, it's a matter of
>> choosing the right tool for the job.
>> 
> 
> How entirely wise.
> 
> "The right tool for the job."
> 
> Bruno at modulix, I salute you.

Fine.  Now what are the criteria?

Why and when do you use a Relational Database?
Why and when do you use an OO language?

These are questions that would require a book to answer.  However, I 
can summarize the answers in a few short sentences.

Relational database systems can be used in situations where there is a 
large amount of complex data to be managed, searched, queried and 
reported.  Enterprise MIS systems are obvious candidates.  The control 
software for a microwave oven is obviously NOT a candidate.

Even when the relational model is a good candidate, the specific vendor 
does not need to be chosen up front.  The decision to use Oracle or 
MySql can be deferred until very late in the implementation process.  
Clearly some companies have made committments to one vendor or the 
other, in which case the decision is moot; but in that case the 
decision is non-technical.  In any case the software should be designed 
such that the vendor can be replaced without undue hardship, which 
means that most of the special features provided by the vendor should 
be ingnored, and the software protected from the vendor API by an 
abstract interface. (using OO technology.)

OO langauges are used whenever the dependencies within a software 
system need to be managed in order to increase cohesion and reduce 
coupling.  All software systems need this, from the largest MIS 
Enterprise system to the lowliest control system for a microwave oven.  
The only software that does not benefit from OO lanaguages is software 
that is so small as to be a single subroutine or small suite of 
functions that can be understood by a single person in an hour or two.






-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 1:11:31 PM
On 2006-05-30 05:54:52 -0500, "David Cressey" <dcressey@verizon.net> said:

> 
> "Alfredo Novoa" <alfredo_novoa@hotmail.com> wrote in message
> news:1148940908.338233.159400@j73g2000cwa.googlegroups.com...
> 
>>> No, a DBMS is a bucket of bits with some low level rules to manage
>>> those bits.  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.
>> 
>>> 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.  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.
> 
> I disagree completely with the above, which seems to have been written by
> Robert Martin.

It was.

> The heart of the system is the data.

*One* heart of the system is the data *model*.  The technology that 
stores the data within that model is a detail.

> For 20 years, I believed that the heart of the system was the application
> code.  I wrote application code.  That's why I believed it.  But I've seen
> enough to convince me otherwise in the last 17 years.
> 
> Not that I didn't say:  "the database".  What if we change database vendors?
> Been there, done that.
> What if we rewrite almost all the application code?  Been there,  done that.
> 
> What if we destroy all the data up to this point?  Time to update your
> resume, everybody!

Granted, granted.  But destroying the data is not the same as isolating 
the data management mechanism from the data model.

Actually, based on your post, I don't think you disagree completely 
with mine.  At most I think you disagree with the emphasis.  My "bucket 
of bits" statement is extreme because I am often found in the situation 
of helping teams of developers who start their projects by saying: "OK, 
we've got Oracle.  Now what?"



-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 1:16:05 PM
On 2006-05-30 06:31:53 -0500, "Erwin" <e.smout@myonline.be> said:

> Little point in preaching to the chuiar of course (how do you spell
> that damn word ?).
> 
> Go tell this on an Otherwise Oriented forum, you'll get dawnbashed.
> 
> That said, application code is still highly important because it's
> needed to fill all the holes that current dbms's still leave wide open
> in the area of constraint enforcement.

This statement is fascinating.  It takes the view that the majority of 
the system is DB and that application code simply fills the cracks.  
The DB represents the bricks and the application code is the mortar.

I disagree with this analogy.  The RDBMS is a mechanisms for storing, 
accessing, reporting, data.  That mechanism can be implemented many 
different ways and need not even be an RDB.  The application code 
defines what the program does with the data.

Some RDBMSs have created an application language in which some 
application programs can be written.  (stored procedures in SQL, or 4th 
gls, etc.)  Typically these langauges are very special purpose and 
vendor specific.  They are not general purpose application programming 
languages.  Therefore, though they have their uses, they should be used 
with caution and restraint.

Even when such language exist, they are not part of the datbase itself. 
 They are still aplication languages.

The application code is not the glue that fills in the cracks.  Instead 
the data is the cargo, and the application code is the railway network, 
engines, and cars, factories, that transform the raw data into useable 
product.  The databases are the warehouses, and a specific vendor's 
DBMS is the material that the warehouse is made of.

Granted those warehouses are complicated structures with their own 
internal access and transport mechanisms to put the data in and get the 
data out, and keep the data safe.  But they aren't the railway network, 
factories, and distribution networks.

> 
> Little true story : some OO proponent in a seminar (well, it was
> actually "in front of an audience") declared that integrity enforcement
> is the responsibility of the application, blahblahblah (he also
> promoted meaningless ID's everywhere in the same breath).  I asked him
> if he was actually aware that the first letter of the word IT stood for
> "information".  His reply was : Yes, but the second stands for
> "technology".

The story may be true, but I'm not sure I get the point.  Frankly, it 
IS the responsibility of the application to enforce integrity.  Oh, the 
DB can enforce it while the data is in the warehouse, but the data 
comes out of the warehouse, gets transported all over the place, gets 
transformed in many different ways into many different products, gets 
presented to many different customers and put into many different 
systems, and for all these activities it is the APPLICATION that must 
enforce the integrity of the data.  The DB loses control once the data 
is out of the warehouse.

Clearly keeping the integrity of the data in the warehouse is 
important.  But that's not the whole story.  It's not even most of the 
story.

Finally, and this is critical to the understaning of my point, the code 
in which data integrity is specified IS application code.  It may be 
written in a special purpose DB language, or it may not.  But it is 
code that supports the application.




-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 1:29:20 PM
Robert Martin wrote:
> On 2006-05-30 06:31:53 -0500, "Erwin" <e.smout@myonline.be> said:
> 
> 
> 

Eeep!

I just realised with my last post that some (but not all) of these posts 
are cross-posted to comp.databases.theory.

We're both flashing red rags to our bulls.

Fine, if that's what we want, just be aware.

(Shocked to read of the end of, "Software Development," UncleBob; just 
as Enums were getting interesting, too.)

-- 
www.EdmundKirwan.com - Home of The Fractal Class Composition.

Download Fractality, free Java code analyzer:
www.EdmundKirwan.com/servlet/fractal/frac-page130.html
0
iamfractal (493)
5/31/2006 1:43:29 PM
On 2006-05-30 16:08:14 -0500, "David Cressey" <dcressey@verizon.net> said:

> I think you have to solve the problem of defining a meaningful and useful
> OODBMS without reference to the relational model.

While I think OODBs can be useful tools, I also think that the domain 
of data and the domain of behavior are never going to be unified.  My 
reasoning is as follows:

In an enterprise there is a large body of interelated data.  This data 
needs to be kept in one place, and in one form, in order to eliminate 
duplication and maintain integrity.

In an enterprise there are many different applications.  Each 
application needs to manipulate a portion (or "view") of the data.  
Very few applications need to maniuplate ALL the data.

The optimum structure for each application is local to it's particular 
function.

the optimum structure for the data has to do with ALL the applications. 
 The structure of the data must make affordances for the most important 
applications, generally at the cost of inefficiency for those 
applications that are infrequent or less important.

So, the design trade-offs for the applications are completely different 
from the design trade-offs for the data model.  Therefore unifying them 
is probably impossible.

To unify them in an OO dabase has even more difficulty.  Objects are an 
admixture of data and behavior.  If we created an enterprise wide OO 
dabase, the objects in that database would have to have all the 
behavior needed by ALL the applications that maniuplate them.  Every 
time one of those behaviors is changed, it puts ALL the other 
applications at risk.  A change to one application means changing 
objects that other applications depend upon.  Therefore there is an 
increased coupling between the applications.  This cannot be allowed to 
go on for very long.

To defend themselves developers export behavior out of the OODB and 
into the applications.  Eventually the OODB is denuded of behavior and 
becomes little more than a network database -- a pile of interelated 
data structures.  At which point it might as well be an RDB.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 1:43:52 PM
On 2006-05-30 07:33:03 -0500, "Tony Andrews" <andrewst@onetel.com> said:

> Alfredo Novoa wrote:
>> Robert Martin wrote:
>>> No, a DBMS is a bucket of bits with some low level rules to manage
>>> those bits.  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.
>> 
>>> 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.  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.
>> 
>> If the mentors are like this, I don't want to imagine the rest.
> 
> Considering the use of so many button-pushingly ludicrous statements
> such as "a DBMS is a bucket of bits" and "swapped out for another at a
> whim", do you not think perhaps Mr Martin was teasing (or goading) you?

I was doing neither.  I was expounding an attitude about DBMSs that I 
have found useful over the years.  When I put a system together I treat 
the DBMS as a detail.  I isolate it from the application code as much 
as possible.  What results is an application design which is deeply 
partitioned into areas that know a lot about the DB and areas that know 
nothing about the DB.  This is just good decoupling.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 1:46:27 PM
On 2006-05-30 09:15:40 -0500, Bob Badour <bbadour@pei.sympatico.ca> said:
>> 
> 
> Are you suggesting that makes Mr. Marin any less of an idiot?

Elliot?


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 1:47:04 PM
On 2006-05-30 16:36:38 -0500, Bob Badour <bbadour@pei.sympatico.ca> said:

> Tony Andrews wrote:
> 
>> Bob Badour wrote:
>> 
>>> Tony Andrews wrote:
>>> 
>>>> Considering the use of so many button-pushingly ludicrous statements
>>>> such as "a DBMS is a bucket of bits" and "swapped out for another at a
>>>> whim", do you not think perhaps Mr Martin was teasing (or goading) you?
>>> 
>>> Are you suggesting that makes Mr. Marin any less of an idiot?
>> 
>> Maybe - if it means he doesn't actually believe something as
>> mind-bendingly stupid as it suggests he believes.  However, in that
>> case it was somewhat foolish of him not to signal that he was joking
>> via an emoticon or whatever, even if perhaps he thought it would be
>> obvious.  I haven't read enough of his posts to know for sure.
> 
> So, in your view it is not idiotic to post something mind-bendingly 
> stupid as long as one doesn't believe what one posts? What is your word 
> for it? Mischievous? I would call it idiotic. A mischievous idiot is 
> still an idiot.

Gentlement, gentlement.  I deeply appreciate the long and arduous 
discussions of my idiocy.  However, I think they might be boring to 
many of the other attendees here.

Thank you for your support.

-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 1:48:33 PM
On 2006-05-30 07:51:15 -0500, "CMCC" <c_jackal@hotmail.com> said:

> Robert Martin wrote:
>> No, a DBMS is a bucket of bits with some low level rules to manage
>> those bits.  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.
>> 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.  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.
> 
> No, a OO application is a bucket of bits with some low level rules to
> manage
> those bits.  An DBMS provides the beavior that the customer
> wants to see.  We can completely eliminate the OO application and
> replace it with
> another of an entirely different form (non OO for example) and
> still have all the business behavior we need.
> 
> The people who sell OO applications have sold you, and the industry, a
> misconception: that the OO application is the heart of the system.
> This is
> flawed.  The heart of the system is the DBMS.  The OO application
> 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.

Let this be a lesson to all you cowards who resort to ad-hominem 
attacks and name calling.  THIS post is a very good rebut to mine.  He 
actually used his BRAIN to invert my argument and throw it back in my 
face.  And he did it without calling me a fool, or an idiot, or a 
trickster.

Carlos, I have to agree with everything you said.  From the 
data=modeler's point of view, the application is just a pile of 
behaiors.  Applications will come and application will go, but the data 
structure will remain.  It may change.  It may grow.  But it will 
always be there!

And this brings us to the real issue at hand.  Each side views the 
other as a bucket of bits!  Is this an error?  Is this a flaw?  No!  
This is good software design!  It is the role of software design to 
abstract away the details.  From the point of view of the application, 
the database is a detail.  From the point of view of the data model the 
applications are details.  And that's the way it SHOULD be.

Application developers get into trouble when they DONT treat the 
database as a detail.

Data modelers get into trouble when the DONT treat the applications as details.

Clearly there must be collaboration accross the divide.  Just as 
clearly each side has it's own discipline, it's own value, and in order 
to create well decoupled design, each side must abstract the other away.

-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 1:55:24 PM
On 2006-05-30 17:54:53 -0500, "Marshall" <marshall.spight@gmail.com> said:

> CMCC wrote:
>> Marshall wrote:
>> 
>> I speak in terms of what he *seems to have written*. Somehow I have
>> to refer to what it is I am talking about! And that is the subject of
>> this thead.
> 
> Grrrr. Okay, fine; I'll do the work. In the future if you have a
> question
> for me, it will be necessary to ask me the full actual question, and
> not refer ambiguously to things written elsewhere.
> 
> [scanning back through the thread ...]
> 
> Okay, maybe you are asking about this:
> 
>> No, a DBMS is a bucket of bits with some low level rules to manage
>> those bits.  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.
>> 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.  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.
> 
> There are many different contexts in which software is developed.
> I will speak relative to enterprise software, which is where DBMS
> software is often found. In that context, the above quoted
> paragraph is pure, unadulterated garbage. It is not simply
> valueless; it is actively harmful. The writer furthermore
> demonstrates that he completely lacks any understanding
> of what the field of data management is, or what it is for,
> or why it is useful.

Ah, it is so easy to generalize about what one person understands.
Are you saying that it is "pure unadulterated garbage" that application 
developers should isolate their application code from the the whims of 
the API designers at Oracle?  Should those application designers use 
every little cute ORACLE trick and call?  Or shoudl they stick to 
standard SQL as proferred by ODBMS or JDBMS, etc.  Should those 
application developers scatter embedded SQL all through their 
application code?  Or should they partition that application code into 
areas that know about the DB and areas that don't?  Should they strive 
to make it possible to swap Oracle for MySql or not?  Should they 
strive even to eliminate the relational flavor of the data from the 
guts of their algorithms, or not.

> The reason why you see crap like this is because it is being
> written by application developers. Application developers are
> great at writing applications, but once they have success in
> that one area, they overgeneralize and begin to believe that
> their techniques are the correct techniques to apply to every
> software development area. However this represents a
> multi-decade regression in the field of data management.

I agree with some of this.  Much of this debate comes from one side not 
understanding the position of the other, and overgeneralizing.  
However, I understand both sides quite wall, having done both and been 
resonsible for both, for damned near 35 years now.  I also agree that 
my "pure unadulterated garbage" above was spoken from the point of view 
of an application developer.  The reason for that, of course, is that 
it was in response to database developers overgeneralizing their own 
point of view.

> Data management in the 1960s lacked any understanding
> of the issues that the field has today. And if the application
> programmers have their way, and the existing field of
> data management is discarded, those same application
> programmers will face all the same problems that the
> programmers of the 1960s did, over again. And over
> the decades, they'll build systems that tackle questions
> like integrity enforcement, ad hoc queries, transaction
> management, etc. Slowly, they will reinvent the field.

It is actually not a bad thing that one side is forced to reinvent the 
other,  Indeed that may be the only way for the two sides to see 
eye-to-eye.  For, of course, the inverse operation is occurring on the 
other side of the divide.  Database application developers are slowly 
learning what software application developers have fought long and hard 
to learn over the last 30 years.  That coupling and cohesion matter, 
and that partitioning, data hiding, and isolation are necesary for 
large applications.

Fortunately, there are groups like this one in which the two sides and 
discuss the issues with each other.  So long as we can avoid calling 
each other names, we might even be able to learn from each other.

> And, if they do so, it would be poetic justice if the
> programmers being born today trash all their work
> in favor of some new fad.

That poetry works in both directions.  I've seen an awful lot of 4gl 
abortions, and deeply chagrined DB programmers over the years.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 2:12:16 PM
Robert Martin schreef:

> On 2006-05-29 17:15:08 -0500, "Alfredo Novoa" <alfredo_novoa@hotmail.com> said:
> >
> > If the mentors are like this, I don't want to imagine the rest.
>
> Excellent ad-hominem argument.  Very well done!  Abandon substantive
> argument all ye who enter this debate.  Concentrate on denegrating the
> man, not the argument!
>

Is our job in the field of INFORMATION technology or in the field of
APPLICATION technology ???

0
e.smout (9)
5/31/2006 2:12:58 PM
Robert Martin wrote:
> On 2006-05-30 07:33:03 -0500, "Tony Andrews" <andrewst@onetel.com> said:
> > Considering the use of so many button-pushingly ludicrous statements
> > such as "a DBMS is a bucket of bits" and "swapped out for another at a
> > whim", do you not think perhaps Mr Martin was teasing (or goading) you?
>
> I was doing neither.  I was expounding an attitude about DBMSs that I
> have found useful over the years.  When I put a system together I treat
> the DBMS as a detail.  I isolate it from the application code as much
> as possible.  What results is an application design which is deeply
> partitioned into areas that know a lot about the DB and areas that know
> nothing about the DB.  This is just good decoupling.

Decoupling is good, if done at an appropriate level.  However, given
your preference for swapping out DBMSs "at a whim" you clearly have no
choice but to use the lowest common denominator abilities of all DBMSs
that might be chosen, which probably amounts to some very simple
low-level DML and SELECT statements.  Then you effectively build your
own pseudo-DBMS on top of this with application code.  What a waste of
time and effort, not to mention the money you spent buying a DBMS of
which you refuse to use 95% of the power!

0
andrewst1 (87)
5/31/2006 2:14:33 PM
On 2006-05-30 17:31:10 -0500, Bob Badour <bbadour@pei.sympatico.ca> said:

> Joe Van Dyk wrote:
>> 
>> Hm, I take it you're not a big fan of the Active Record pattern?
> 
> Only a complete idiot would be. "Let's take something with the full 
> power of predicate logic and leave it with, um, restriction. Yeah, 
> that'll bring it down to the level we want!"

I have no idea why you say that.  The Active Record pattern 
(http://www.martinfowler.com/eaaCatalog/activeRecord.html) is just a 
way to organize some application code in a way that provides access to 
the database beneath.  It does not restrict predicate logic in any way.

I'm not a big fan of this pattern for most applications because it 
couples the database logic and the business logic into a single class.  
I prefer Table Data Gateway structures that allow me to put the DB 
related code into one class, and the business rules in another.  
However, for some simple applications I have used Active Record.

It does not take a "complete idiot" to value these design patterns.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 2:21:13 PM
On 2006-05-30 19:56:34 -0500, "Alfredo Novoa" <alfredo_novoa@hotmail.com> said:

> Indeed, it is a very stupid way to lose almost all the power a DBMS
> offers.

Ah, another substantive post.  Good job!  Keep up the good work.

Now, can you tell us what the Active Record pattern is?
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 2:22:21 PM
Robert Martin wrote:
> The decision to use Oracle is NOT at the core of the system.

Correct.


> The decision to use SQL or Relational technology is NOT at the
> core of the system.

Incorrect.

Would you also say that the decision of whether to use an OOPL
or an FPL is a detail? If your system does data management,
then at the core of the system you should have a Data Base
Management System. Not to use the tools best suited for
the problem is irresponsible.


Marshall

0
5/31/2006 2:32:34 PM
Robert Martin wrote:
>
> I disagree with this analogy.  The RDBMS is a mechanisms for storing,
> accessing, reporting, data.

If your understanding of the role of the DBMS only extends that
far, then no wonder you misunderstand so much.

Storage is an incidental feature of a DBMS. A thing can be
a DBMS and not do persistence.

Your use of the word "access" again reinforces the idea
that you view the DBMS as merely a storage mechanism.

That you completely fail to mention the *primary* uses
of a DBMS is telling. Structure, integrity, and manipulation
are the central strengths of a DBMS. The pride of
application developers (or simply their lack of education)
makes them want to reserve these functions for their
application code, because that's the only hammer they
know how to swing well. But application code is an
inferior tool for these.


> That mechanism can be implemented many
> different ways and need not even be an RDB.  The application code
> defines what the program does with the data.

It appears that the OOPL mantra of "state and behavior" has
gotten you to the point of believing that data structures and
imperative functions are the only way to work with a computer.
You may wish to consider the possibility that this is a very
limiting, perhaps even stunting way to look at the world.


Marshall

0
5/31/2006 2:45:00 PM
"David Cressey" <dcressey@verizon.net> wrote in message
news:0wVeg.6314$o%3.5220@trndny07...

> The heart of the system is the data.

The blood is the data.

> For 20 years, I believed that the heart of the system was the application
> code.  I wrote application code.  That's why I believed it.  But I've seen
> enough to convince me otherwise in the last 17 years.

> Not that I didn't say:  "the database".  What if we change database
vendors?
> Been there, done that.

> What if we rewrite almost all the application code?  Been there,  done
that.

What if you delete all the application code ?

> What if we destroy all the data up to this point?  Time to update your
> resume, everybody!

What if you update the data ?


0
x
5/31/2006 2:55:17 PM
Robert Martin ha escrito:

> Excellent ad-hominem argument.  Very well done!  Abandon substantive
> argument all ye who enter this debate.  Concentrate on denegrating the
> man, not the argument!

You proved that it does no make any sense to try to discuss with you.

You only deserve to be expeditiously debunked.


Regards
  Alfredo
              |

0
alfredono (16)
5/31/2006 3:19:25 PM
Marshall ha escrito:

> Bob Badour wrote:
> > Alfredo Novoa wrote:
> >
> > > If the mentors are like this, I don't want to imagine the rest.
> >
> > Ugh. Alfredo, why did you have to ruin my evening? The ignorance and
> > stupidity is astounding, isn't it?
>
> [removed comp.object]
>
> Agreed.

Marshall, I crossposted the thread looking for support for his public
debunking (he is a sort of authority in the OO world), and it worked
very well :-)

Thanks to the group!


Regards
  Alfredo

0
Alfredo
5/31/2006 3:41:22 PM
frebe73@gmail.com wrote:
>>I have certainly found systems that should NEVER use an RDBMS.  But I
>>have never found a system that could not benefit from a good OO
>>language.
> 
> 
> But there are many (enterprise) applications there OOAD is not
> suitable. Some OO languages (such as java) has disadvantages because
> they don't allow first-order functions and function pointers.

I don't know Java, but if your statement about Java disadvantages is 
true, that's a problem with Java -- not with OO.

Joe
0
joe.vandyk (160)
5/31/2006 3:46:06 PM
Robert Martin wrote:
> On 2006-05-30 05:32:15 -0500, "Alfredo" <alfredono@gmail.com> said:
> 
>> Bob,
>>
>> You had the "object" warning in the subject line O:-)
>>
>> When managers want a new information system they usually contact with
>> an application programmer (without any database skills) trained by
>> supposed experts like this. No database expert is asked in the process.
>>
>> I think that "mentors" like this should be debunked. They are making a
>> lot more harm than Dawn and the likes.
> 
> This begins to approach a substantive argument, so I'll address it with 
> substance and ignore the obligatory ad-hominem cowardice.
> 
> There is a difference between data modeling and databases.  Data 
> modeling is an important discipline that must be considered for every 
> application.  A good data model is a critical part of a good system 
> architecture and, along with the partitioning of behavior, is close to 
> the core value of the system.
> 
> A DBMS is a technical detail.  Decisions about it should be deferred as 
> long as possible. The decision to use Oracle is NOT at the core of the 
> system.

Agreed.


   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.

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.

As a logical data model, the relational model works very well while the 
available alternatives work very, very poorly by comparison. 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.

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.

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.
0
bbadour (434)
5/31/2006 3:53:23 PM
Robert Martin wrote:

> On 2006-05-30 05:54:52 -0500, "David Cressey" <dcressey@verizon.net> said:
> 
>> "Alfredo Novoa" <alfredo_novoa@hotmail.com> wrote in message
>> news:1148940908.338233.159400@j73g2000cwa.googlegroups.com...
>>
>>>> No, a DBMS is a bucket of bits with some low level rules to manage
>>>> those bits.  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.
>>>
>>>> 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.  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.
>>
>> I disagree completely with the above, which seems to have been written by
>> Robert Martin.
> 
> It was.
> 
>> The heart of the system is the data.
> 
> *One* heart of the system is the data *model*.  The technology that 
> stores the data within that model is a detail.
> 
>> For 20 years, I believed that the heart of the system was the application
>> code.  I wrote application code.  That's why I believed it.  But I've 
>> seen
>> enough to convince me otherwise in the last 17 years.
>>
>> Not that I didn't say:  "the database".  What if we change database 
>> vendors?
>> Been there, done that.
>> What if we rewrite almost all the application code?  Been there,  done 
>> that.
>>
>> What if we destroy all the data up to this point?  Time to update your
>> resume, everybody!
> 
> Granted, granted.  But destroying the data is not the same as isolating 
> the data management mechanism from the data model.

More ignorant tripe. Do you even have a clue what a data model is? What 
sort of data model you are talking about? Without that, what you wrote 
is not only wrong but essentially meaningless.


> Actually, based on your post, I don't think you disagree completely with 
> mine.  At most I think you disagree with the emphasis.  My "bucket of 
> bits" statement is extreme because I am often found in the situation of 
> helping teams of developers who start their projects by saying: "OK, 
> we've got Oracle.  Now what?"

Sadly, I have been paid large sums of money to fix the problems created 
when teams started with "We've got objects. Woo hoo!" instead.
0
bbadour (434)
5/31/2006 4:00:05 PM
Robert Martin wrote:
> On 2006-05-30 04:09:34 -0500, frebe73@gmail.com said:
>
> >> The problem is that some persons here are truly hard-core RDBMS
> >> fanatics and and absolutely unable to understand that there's a life
> >> outside RDBMS. RDBMS are really great for some things, and just suck for
> >> some other things.
> >
> > Maybe the problem also is that some persons here are truly hard-core OO
> > fanatics and absolutely unable to understand that there's a life
> > outside OO. OO are really great for some things, and just suck for some
> > other things.
>
> I won't argue that OO has not been over-hyped.  Certainly it has.
> However, the principles of OO design are really just principles of good
> software design.  OO langauges simply gives us some good tools to help
> us managine coupling and cohesion better.

I have not found a way to use "coupling and cohesion" as an objective
metric. It seems to depend on one's personal, internal view of
software, change-patterns, and life rather than a "hard" metric that
settles debates like these. My C&C complaints can be found at:

http://c2.com/cgi/wiki?CouplingAndCohesion

>
> I have certainly found systems that should NEVER use an RDBMS.  But I
> have never found a system that could not benefit from a good OO
> language.
>
> A good OO designer is not a fanatic about OO, S/he is a disciplined
> software designer that is able to use the tools of OO.
>
> A good software designer can use both OO and RDB tools as, and when,
> needed.  However, RDB tools are mechanisms that can be deferred both in
> time and space to be considered later and partitioned into a small
> segment of the code.  OO tools are used throughout the design and
> implementation process and cannot be deferred either in time or space.

This sounds like the "RDBMS is a low-level tool/service" argument. I
have to disagree. One can treat it merely as a filing system, but can
also treat it as a sophisticated modeling tool.

In declarative programming the implementation is what is considered
"low level", not the other way around. One can create a kind of domain-
or app-specific declarative "language" of a sort with tables (or at
least attributes).

For an analogy, consider a programming language interpreter. It takes
your input file and turns it into a data structure, and then operates
on the attributes in that data structure. The implementation can be
considered lower-level detail. A data structure may have an Add
operation and two numeric operands hanging off of it. We don't have to
worry much about how Add is implemented when looking at this data
structure, we just concentrate on the fact that it is an Add node.

Declarative programming is kind of like that: you focus on what
attributes you fill in or create to have an activity carried out rather
than on how it is carried out. Some have characterized it as "turning
programming into data entry", which has some truth to it.

Now I agree that many existing tools and vendors don't make this very
easy to do, and it is not taught as a technique. The vendors tilt
toward behavior-oriented solutions that OO encourages or the "big-iron"
Oracle view of DBs such that declarative (data-centric) modeling is a
bit tough to do in the current environment.

I won't claim that declarative approaches based on tables are
objectively better than the behavioral tilt of OOP. They both "run". I
just know that they fit the way I think better. I can sift and change
presentation of declarative info much easier than I can with behavioral
code. It is tough to "query" programming code.

And, relational seems to offer more consistency. OOP results in
"structures" that are not significantly different from the 1960's
navigational structuring messes that motivated Dr. Codd to invent
relational.  Navigational is the Go To of structuring in my opinion. If
there is a consistent pattern that helps one think and reason about OO,
nobody has documented it, at least not with a consensus.

Relational is based on set theory, OOP on hierarchies and pointers. In
my book, sets win because hierarchies don't fit real world change well,
and pointers have no known discipline to them. "GOF Patterns" have been
one suggestion, but there is little consistent guidence about where and
when to use them. In relational thinking patterns tend to be a specific
viewpoint, not a thing you hard-wire into code or software.
Normalization rules tend to dictate the shape of things and less so the
whims of designers.


>
>
> --
> Robert C. Martin (Uncle Bob)  | email: unclebob@objectmentor.com

-T-

0
topmind (2124)
5/31/2006 4:09:05 PM
Robert Martin wrote:
> Ah, it is so easy to generalize about what one person understands.
> Are you saying that it is "pure unadulterated garbage" that application
> developers should isolate their application code from the the whims of
> the API designers at Oracle?

Database API is SQL. Everything else is auxiliary technology that
supports it. JDBC is merely a low level programmatic glue between SQL
and Java, PL/SQL (stored procedures) are the way to enhance SQL with
programmatic relations (aka functions).

> Should those application designers use
> every little cute ORACLE trick and call?

Sometimes you have no choice. Consider hierarchical queries, for
example. Would you go through all the trouble learning/implementing
nested sets/intervals, materialized path etc, or rather write
relatively straightforward query based on proprietory "connect by" SQL
feature?

> Or shoudl they stick to
> standard SQL as proferred by ODBMS or JDBMS, etc.  Should those
> application developers scatter embedded SQL all through their
> application code?

This is a culprit that OO people stubbornly refuse to understand.
Embedding high level language (SQL) statements inside low level
language (Java) is perfectly reasonable. What you propose instead, a
pathetic set of classes that build the query dynamically?

> Or should they partition that application code into
> areas that know about the DB and areas that don't?  Should they strive
> to make it possible to swap Oracle for MySql or not?

Writing generic SQL might be a good idea, but sometimes you have to use
proprietory feature. It saves time in a short term.

> Should they
> strive even to eliminate the relational flavor of the data from the
> guts of their algorithms, or not.

This is rethorical question.

        |

0
5/31/2006 4:14:52 PM
> I don't know Java, but if your statement about Java disadvantages is
> true, that's a problem with Java -- not with OO.

In a true OO language there are no first order functions. Some OO
languages, like Python, are a little more pragmatic and has some non-OO
features too.

Fredrik Bertilsson
http://frebe.php0h.com

0
frebe73 (444)
5/31/2006 4:21:45 PM
Robert Martin wrote:
> Application developers get into trouble when they DONT treat the
> database as a detail.

Robert, you claim 35 years of application programming experience. Have
you ever come across a performance problem when database is accessed
via API

getItemIdList
getItemDetail

so that a single jsp page issued a hundred SQL statements instead of a
single one? Come on, this one is so common that it surfaces on every
performance meeting.

0
5/31/2006 4:26:46 PM
> Even when the relational model is a good candidate, the specific vendor
> does not need to be chosen up front.  The decision to use Oracle or
> MySql can be deferred until very late in the implementation process.
> Clearly some companies have made committments to one vendor or the
> other, in which case the decision is moot; but in that case the
> decision is non-technical.  In any case the software should be designed
> such that the vendor can be replaced without undue hardship, which
> means that most of the special features provided by the vendor should
> be ingnored, and the software protected from the vendor API by an
> abstract interface. (using OO technology.)

I am afraid you are not talking about JDBC/ADO/ODBC as an abstract
interface. Making custom abstract interfaces for every application is a
very clumsy an inefficient way to achieve vendor independence. If you
don't think an interface such as JDBC gives you vendor independence,
use another generic interface on top.

Fredrik Bertilsson
http://frebe.php0h.com

0
frebe73 (444)
5/31/2006 4:28:08 PM
Robert Martin wrote:

> On 2006-05-30 06:31:53 -0500, "Erwin" <e.smout@myonline.be> said:
> 
>> Little point in preaching to the chuiar of course (how do you spell
>> that damn word ?).
>>
>> Go tell this on an Otherwise Oriented forum, you'll get dawnbashed.
>>
>> That said, application code is still highly important because it's
>> needed to fill all the holes that current dbms's still leave wide open
>> in the area of constraint enforcement.
> 
> This statement is fascinating.  It takes the view that the majority of 
> the system is DB and that application code simply fills the cracks.  The 
> DB represents the bricks and the application code is the mortar.
> 
> I disagree with this analogy.  

Which is highly indicative of your profound ignorance, which was noted 
previously.


The RDBMS is a mechanisms for storing,
> accessing, reporting, data.  That mechanism can be implemented many 
> different ways and need not even be an RDB.

If one is stupid, ignorant or has no choice, I suppose one might use 
something different. The RDBMS is also a mechanism for manipulating 
data, for security, for integrity, for derivation, for all-round 
management -- as the name implies.


   The application code
> defines what the program does with the data.

Other than enter, manipulate, report and derive, what does one do with data?

[irrelevant and incorrect metaphors snipped]


>> Little true story : some OO proponent in a seminar (well, it was
>> actually "in front of an audience") declared that integrity enforcement
>> is the responsibility of the application, blahblahblah (he also
>> promoted meaningless ID's everywhere in the same breath).  I asked him
>> if he was actually aware that the first letter of the word IT stood for
>> "information".  His reply was : Yes, but the second stands for
>> "technology".
> 
> The story may be true, but I'm not sure I get the point.  Frankly, it IS 
> the responsibility of the application to enforce integrity.  Oh, the DB 
> can enforce it while the data is in the warehouse, but the data comes 
> out of the warehouse, gets transported all over the place, gets 
> transformed in many different ways into many different products, gets 
> presented to many different customers and put into many different 
> systems, and for all these activities it is the APPLICATION that must 
> enforce the integrity of the data.

Once again, you expose your ignorance. If you remove the data from the 
data management system, obviously, you force yourself to re-invent other 
tools to manage the data--however poorly. It strikes me as rather stupid 
to choose the wrong tool for the job, though.


   The DB loses control once the data
> is out of the warehouse.

Here, you expose sloppy thinking. A database is simply a set of facts, 
which renders your sentence nonsense. If one were charitable, one might 
substitute 'data management system' where you put DB, but then the 
statement would become unremarkable and pointless.


> Clearly keeping the integrity of the data in the warehouse is 
> important.  But that's not the whole story.  It's not even most of the 
> story.

Yes, that's true. If the protagonist chooses at the outset to do stupid 
things (ie. to manage the data without a management system, to travel to 
an island full of dinosaurs, to catch the maneating 30 foot great white 
shark etc.), then Act II generally follows the protagonist as he 
struggles against the harmful consequences of his stupid choices, and 
Act III culminates the story with the protagonist either overcoming his 
stupidity or succumbing.

That makes for entertaining drama, but I wasn't aware that the goal of 
computing science or information technology was to create drama or to 
entertain ourselves, per se.


> Finally, and this is critical to the understaning of my point, the code 
> in which data integrity is specified IS application code.  It may be 
> written in a special purpose DB language, or it may not.  But it is code 
> that supports the application.

Code? Do you consider a well-formed formula code? Are logic predicates 
code? I am just curious what you define as code. If you define code to 
include everything, then your statement is true if unremarkable and 
uninteresting.
0
bbadour (434)
5/31/2006 4:31:29 PM
Robert Martin wrote:

> On 2006-05-30 16:36:38 -0500, Bob Badour <bbadour@pei.sympatico.ca> said:
> 
>> Tony Andrews wrote:
>>
>>> Bob Badour wrote:
>>>
>>>> Tony Andrews wrote:
>>>>
>>>>> Considering the use of so many button-pushingly ludicrous statements
>>>>> such as "a DBMS is a bucket of bits" and "swapped out for another at a
>>>>> whim", do you not think perhaps Mr Martin was teasing (or goading) 
>>>>> you?
>>>>
>>>> Are you suggesting that makes Mr. Marin any less of an idiot?
>>>
>>> Maybe - if it means he doesn't actually believe something as
>>> mind-bendingly stupid as it suggests he believes.  However, in that
>>> case it was somewhat foolish of him not to signal that he was joking
>>> via an emoticon or whatever, even if perhaps he thought it would be
>>> obvious.  I haven't read enough of his posts to know for sure.
>>
>> So, in your view it is not idiotic to post something mind-bendingly 
>> stupid as long as one doesn't believe what one posts? What is your 
>> word for it? Mischievous? I would call it idiotic. A mischievous idiot 
>> is still an idiot.
> 
> Gentlement, gentlement.  I deeply appreciate the long and arduous 
> discussions of my idiocy.  However, I think they might be boring to many 
> of the other attendees here.
> 
> Thank you for your support.

With all due respect, what on earth makes you think anything you write 
is the least bit interesting?
0
bbadour (434)
5/31/2006 4:34:36 PM
Robert Martin wrote:
> On 2006-05-30 07:51:15 -0500, "CMCC" <c_jackal@hotmail.com> said:
> 
>> Robert Martin wrote:
>>
>>> No, a DBMS is a bucket of bits with some low level rules to manage
>>> those bits.  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.
>>> 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.  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.
>>
>> No, a OO application is a bucket of bits with some low level rules to
>> manage
>> those bits.  An DBMS provides the beavior that the customer
>> wants to see.  We can completely eliminate the OO application and
>> replace it with
>> another of an entirely different form (non OO for example) and
>> still have all the business behavior we need.
>>
>> The people who sell OO applications have sold you, and the industry, a
>> misconception: that the OO application is the heart of the system.
>> This is
>> flawed.  The heart of the system is the DBMS.  The OO application
>> 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.
> 
> Let this be a lesson to all you cowards who resort to ad-hominem attacks 
> and name calling.

Ad-hominem attacks like calling someone a coward? Idiot.


   THIS post is a very good rebut to mine.

I disagree.


He actually
> used his BRAIN to invert my argument and throw it back in my face.  And 
> he did it without calling me a fool, or an idiot, or a trickster.

Regurgitating what you wrote and doing a couple global substitutions 
doesn't use much of a brain. Neither does it explain any more than 
simply pointing out that you are an ignorant idiot.

[irrelevancies snipped]
0
bbadour (434)
5/31/2006 4:41:54 PM
> Decoupling is good, if done at an appropriate level.  However, given
> your preference for swapping out DBMSs "at a whim" you clearly have no
> choice but to use the lowest common denominator abilities of all DBMSs
> that might be chosen, which probably amounts to some very simple
> low-level DML and SELECT statements.  Then you effectively build your
> own pseudo-DBMS on top of this with application code.  What a waste of
> time and effort, not to mention the money you spent buying a DBMS of
> which you refuse to use 95% of the power!

This is simply not true. I have been converting a major enterprise
application from Informix to also support Oracle and SQL Server. I
think that we had to rewrite less than 5% of the SQL statements. In
almost every case we were able to use the same query for all vendors
without changing the semantics of the original query. In some severe
cases we had to "wash" the SQL statement using simple find/replace
functions, to fit different vendors. The conclusion was obvious:
Continue to embedd (ANSI) SQL in the application, but make your own
(JDBC/ODBC/ADO) driver on top of the vendor driver, to eliminate the
remaining incompatibilites between vendors.

Fredrik Bertilsson
http://frebe.php0h.com

0
frebe73 (444)
5/31/2006 4:43:43 PM
I don't see how the issue of proprietary SQL is any different than a
proprietary app language.  How is being married to Java worse than
being married to Oracle? Your argument seems to be "we will use a
prioprietary app language to wrap/escape a proprietary query language".
You cut off your left hand to save your right hand.

The query/SQL house indeed needs a lot of cleaning, and perhaps an
overhaul. However, the alternatives are grappling with similar
problems.

The fact that SQL is somewhat standardized is a *bonus*, not a fault.
I've had to switch and learn new programming languages often enough
that it is not fun anymore. However, one of the few semi-constants is
SQL. I change app language but SQL is there almost just as it was in
the with last app language that fell out of style.

If OO'ers had their way, they would probably fracture the query market
the same way they fractured the GUI market -- a different GUI engine
for each different OO language. OO API's have failed to find a way to
be app-language neutrual (without bloated verbose adaptors).

-T-

0
topmind (2124)
5/31/2006 4:50:20 PM
Robert Martin wrote:

> On 2006-05-30 17:31:10 -0500, Bob Badour <bbadour@pei.sympatico.ca> said:
> 
>> Joe Van Dyk wrote:
>>
>>> Hm, I take it you're not a big fan of the Active Record pattern?
>>
>> Only a complete idiot would be. "Let's take something with the full 
>> power of predicate logic and leave it with, um, restriction. Yeah, 
>> that'll bring it down to the level we want!"
> 
> I have no idea why you say that.  The Active Record pattern 
> (http://www.martinfowler.com/eaaCatalog/activeRecord.html) is just a way 
> to organize some application code in a way that provides access to the 
> database beneath.  It does not restrict predicate logic in any way.

This is how you prove that you are not only ignorant but stupid as well. 
How do you join two active records? What does it mean to join them? How 
do you project an active record? What does it mean to project? Union? 
Intersection? Difference? Division? Closure?

Fowler is an idiot. Given two formal systems: one very powerful system 
operating at the level of intent and the other very low-level system 
obscuring intent, his solution is to cripple the powerful one down to 
match low-level one.


> I'm not a big fan of this pattern for most applications because it 
> couples the database logic and the business logic into a single class.

Here, you once again prove your ignorance. The database logic is 
necessarily the business logic, and predicate logic (ie. the relational 
model) is the best formalism we have for symbolic manipulation of logic 
statements. You prove your stupidity by choosing to throw away predicate 
logic in favor of an ad-hoc construct invented for creating large, 
unpredictable state machines.


> I prefer Table Data Gateway structures that allow me to put the DB 
> related code into one class, and the business rules in another.

Here, again, you choose to forego the power of predicate logic for 
expressing business rules in favor of the ad-hoc construct invented for 
creating large, unpredictable state machines.


> However, for some simple applications I have used Active Record.

That's nice. [rolls eyes]


> It does not take a "complete idiot" to value these design patterns.

Okay, I exaggerated a little. Any sort of idiot might value these design 
patterns and not just a complete idiot. Even still, it does require a 
remarkable level of stupidity and ignorance to favor them over predicate 
logic for manipulating logic statements.
0
bbadour (434)
5/31/2006 5:00:56 PM
Robert Martin wrote:
>
> Let this be a lesson to all you cowards who resort to ad-hominem
> attacks and name calling.  THIS post is a very good rebut to mine.  He
> actually used his BRAIN to invert my argument and throw it back in my
> face.  And he did it without calling me a fool, or an idiot, or a
> trickster.

Bob,

You can't validly at once call people cowards, and say they
are not using their BRAINS, and also compain about their
name-calling and impoliteness. If name-calling should not
be done, why are you doing it? The condescension and
attempt to claim the high ground is inconsistent with
simultaneous use of the same tactics that you are
complaining about.


Marshall

PS. "BRAINS" should be said in a zombie voice.

0
5/31/2006 5:04:00 PM
Robert Martin wrote:

> On 2006-05-30 19:56:34 -0500, "Alfredo Novoa" 
> <alfredo_novoa@hotmail.com> said:
> 
>> Indeed, it is a very stupid way to lose almost all the power a DBMS
>> offers.
> 
> Ah, another substantive post.  Good job!  Keep up the good work.
> 
> Now, can you tell us what the Active Record pattern is?

He already did. You were just too stupid to comprehend a simple english 
sentence with an infinitive in the subjective completion.

Let me rephrase his answer to explain instead what the Active Record 
Pattern does:

The active record pattern cripples a data management system for no clear 
benefit.
0
bbadour (434)
5/31/2006 5:06:04 PM
Alfredo Novoa wrote:

> Robert Martin ha escrito:
> 
>>Excellent ad-hominem argument.  Very well done!  Abandon substantive
>>argument all ye who enter this debate.  Concentrate on denegrating the
>>man, not the argument!
> 
> You proved that it does no make any sense to try to discuss with you.
> 
> You only deserve to be expeditiously debunked.

To be fair, you did not actively debunk what he wrote. To an educated 
and informed person, what he wrote was incoherent on its face, and we 
all know Date's _Principle of Incoherence_ so I can forgive you for not 
walking the extra 10 miles to spoonfeed the idiot.

But the sad truth is: I am certain he lacks the cognitive ability to 
recognize just how incoherent what he wrote is. I am sure he believes he 
wrote something coherent that deserves more effort.
0
bbadour (434)
5/31/2006 5:13:47 PM
Bob Badour wrote:
> Fowler is an idiot. Given two formal systems: one very powerful system
> operating at the level of intent and the other very low-level system
> obscuring intent, his solution is to cripple the powerful one down to
> match low-level one.

This is kind of extreme statement. Reading Mr Fowler's "Refactoring"
was a pleasant experience back in 97. I couldn't help exclaming "I
should have written that!" Unfortunately, Fowler's recent voyage into
data management area is disappointing.

0
5/31/2006 5:22:16 PM
Mikito Harakiri wrote:
> Robert Martin wrote:
> 
>>Ah, it is so easy to generalize about what one person understands.
>>Are you saying that it is "pure unadulterated garbage" that application
>>developers should isolate their application code from the the whims of
>>the API designers at Oracle?
> 
> 
> Database API is SQL. Everything else is auxiliary technology that
> supports it. JDBC is merely a low level programmatic glue between SQL
> and Java, PL/SQL (stored procedures) are the way to enhance SQL with
> programmatic relations (aka functions).
> 
> 
>>Should those application designers use
>>every little cute ORACLE trick and call?
> 
> 
> Sometimes you have no choice. Consider hierarchical queries, for
> example. Would you go through all the trouble learning/implementing
> nested sets/intervals, materialized path etc, or rather write
> relatively straightforward query based on proprietory "connect by" SQL
> feature?
> 
> 
>>Or shoudl they stick to
>>standard SQL as proferred by ODBMS or JDBMS, etc.  Should those
>>application developers scatter embedded SQL all through their
>>application code?
> 
> 
> This is a culprit that OO people stubbornly refuse to understand.
> Embedding high level language (SQL) statements inside low level
> language (Java) is perfectly reasonable. What you propose instead, a
> pathetic set of classes that build the query dynamically?

I'm not sure what you mean by "a pathetic set of classes that build the 
query dynamically".  Are you referring to Object-Relational Mappers here?

Joe

0
joe.vandyk (160)
5/31/2006 5:23:49 PM
Mikito Harakiri wrote:
> Robert Martin wrote:
> 
>>Application developers get into trouble when they DONT treat the
>>database as a detail.
> 
> 
> Robert, you claim 35 years of application programming experience. Have
> you ever come across a performance problem when database is accessed
> via API
> 
> getItemIdList
> getItemDetail
> 
> so that a single jsp page issued a hundred SQL statements instead of a
> single one? Come on, this one is so common that it surfaces on every
> performance meeting.

This problem is easily solved via caching.

Joe

0
joe.vandyk (160)
5/31/2006 5:24:44 PM
Robert Martin wrote:
> On 2006-05-30 17:54:53 -0500, "Marshall" <marshall.spight@gmail.com> said:
> >
> > There are many different contexts in which software is developed.
> > I will speak relative to enterprise software, which is where DBMS
> > software is often found. In that context, the above quoted
> > paragraph is pure, unadulterated garbage. It is not simply
> > valueless; it is actively harmful. The writer furthermore
> > demonstrates that he completely lacks any understanding
> > of what the field of data management is, or what it is for,
> > or why it is useful.
>
> [...]
> Are you saying that it is "pure unadulterated garbage" that application
> developers should isolate their application code from the the whims of
> the API designers at Oracle?  Should those application designers use
> every little cute ORACLE trick and call?  Or shoudl they stick to
> standard SQL as proferred by ODBMS or JDBMS, etc.  Should those
> application developers scatter embedded SQL all through their
> application code?  Or should they partition that application code into
> areas that know about the DB and areas that don't?  Should they strive
> to make it possible to swap Oracle for MySql or not?  Should they
> strive even to eliminate the relational flavor of the data from the
> guts of their algorithms, or not.

Seven consecutive leading questions and my parser runs out
of memory. Uh, let's see: yes, as appropriate, ideally (assuming
you mean JDBC; I don't know what JDBMS is), no-of-course-
not-I-never-suggested-otherwise, yes, no, probably not.

(Perhaps we could come up with a better format for dialog.)

(Why are you so stuck on Oracle, by the way? Are you thinking
I'm an Oracle salesman?)


> > The reason why you see crap like this is because it is being
> > written by application developers. Application developers are
> > great at writing applications, but once they have success in
> > that one area, they overgeneralize and begin to believe that
> > their techniques are the correct techniques to apply to every
> > software development area. However this represents a
> > multi-decade regression in the field of data management.
>
> I agree with some of this.  Much of this debate comes from one side not
> understanding the position of the other, and overgeneralizing.
> However, I understand both sides quite wall, having done both and been
> resonsible for both, for damned near 35 years now.

Your CV is excellent. Mine is too.


> I also agree that
> my "pure unadulterated garbage" above was spoken from the point of view
> of an application developer.  The reason for that, of course, is that
> it was in response to database developers overgeneralizing their own
> point of view.

My point of view is also that of an application developer, because that
is what the vast majority of my career has been. However I have
been quite impressed with the achievements of the field of data
management, and have worked hard to educate myself in it.

I have not noticed the same level of attempting to destroy
and belittle the achivements of the other side coming from
the data management camp as I have from the application
developer camp. (Although I will grant you it occurs.) I think
it may have to do with the fact that the dbms people have
always had to work with application developers, while many
of the application developers have only recently had to start
working with the dbms camp.


> > Data management in the 1960s lacked any understanding
> > of the issues that the field has today. And if the application
> > programmers have their way, and the existing field of
> > data management is discarded, those same application
> > programmers will face all the same problems that the
> > programmers of the 1960s did, over again. And over
> > the decades, they'll build systems that tackle questions
> > like integrity enforcement, ad hoc queries, transaction
> > management, etc. Slowly, they will reinvent the field.
>
> It is actually not a bad thing that one side is forced to reinvent the
> other,  Indeed that may be the only way for the two sides to see
> eye-to-eye.

Hmmm, well, I see your point but it is a bit panglossian for my
tastes. I would like to think the two sides could come together
and learn from each other. I have tried to embody that myself,
as an application programmer studying the ways of the RM
at the Jedi Academy. I would like to believe there is a more
mature discipline waiting to be born, that encompasses the
achievments of each, and unifies them. They are not mutually
antagonistic; only the actual people are. :-)


> For, of course, the inverse operation is occurring on the
> other side of the divide.  Database application developers are slowly
> learning what software application developers have fought long and hard
> to learn over the last 30 years.  That coupling and cohesion matter,
> and that partitioning, data hiding, and isolation are necesary for
> large applications.
>
> Fortunately, there are groups like this one in which the two sides and
> discuss the issues with each other.  So long as we can avoid calling
> each other names, we might even be able to learn from each other.

OT: I am not sure a lack of namecalling is a prerequisite. I actually
begin to suspect that namecalling, on usenet at least, is inevitable.

 
Marshall

0
5/31/2006 5:26:23 PM
> A DBMS is a technical detail.  Decisions about it should be deferred as long as possible. The decision to use Oracle is NOT at the core of the system.  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.

Finally, someone as dumb as me :)

0
neo55592 (356)
5/31/2006 5:26:34 PM
Robert Martin wrote:
> On 2006-05-30 19:56:34 -0500, "Alfredo Novoa" <alfredo_novoa@hotmail.com> said:
>
> > Indeed, it is a very stupid way to lose almost all the power a DBMS
> > offers.
>
> Ah, another substantive post.  Good job!  Keep up the good work.

It may not be substantive in the sense that it doesn't inform for
those who are not already aware of the problem. But it does
very accurately label a very real problem with a common practice.
When I read Alfredo's post, I though "yes, that's exactly the problem."


Marshall

0
5/31/2006 5:29:45 PM
Alfredo Novoa wrote:
> Marshall ha escrito:
>
> > Bob Badour wrote:
> > > Alfredo Novoa wrote:
> > >
> > > > If the mentors are like this, I don't want to imagine the rest.
> > >
> > > Ugh. Alfredo, why did you have to ruin my evening? The ignorance and
> > > stupidity is astounding, isn't it?
> >
> > [removed comp.object]
> >
> > Agreed.
>
> Marshall, I crossposted the thread looking for support for his public
> debunking (he is a sort of authority in the OO world), and it worked
> very well :-)
>
> Thanks to the group!

In retrospect, my decision to trim comp.object in my reply was
probably incorrect. I remain somewhat conflict-averse; it
is a character weakness. My bad.


Marshall

0
Marshall
5/31/2006 5:36:03 PM
Bob Badour wrote:
> Robert Martin wrote:
>
> > Granted, granted.  But destroying the data is not the same as isolating
> > the data management mechanism from the data model.
>
> More ignorant tripe. Do you even have a clue what a data model is? What
> sort of data model you are talking about? Without that, what you wrote
> is not only wrong but essentially meaningless.

Wow, I missed that one completely. "Isolate the data management
mechanism from the data model." How in tarnation is the data
manager doing to manage the data if it is isolated from the
data model?


> Sadly, I have been paid large sums of money to fix the problems created
> when teams started with "We've got objects. Woo hoo!" instead.

LOL! The "Woo hoo" really makes it.


Marshall

0
5/31/2006 5:44:04 PM
Joe Van Dyk wrote:
> Mikito Harakiri wrote:
> > Robert Martin wrote:
> >
> >>Application developers get into trouble when they DONT treat the
> >>database as a detail.
> >
> >
> > Robert, you claim 35 years of application programming experience. Have
> > you ever come across a performance problem when database is accessed
> > via API
> >
> > getItemIdList
> > getItemDetail
> >
> > so that a single jsp page issued a hundred SQL statements instead of a
> > single one? Come on, this one is so common that it surfaces on every
> > performance meeting.
>
> This problem is easily solved via caching.

Yep.

User: "I updated the stupid item, why didn't it refresh on the damn
screen?"
Programmer: "Fixing this problem requires to make the cache as
sophisticated as DBMS. Not feasible in the current release".

0
5/31/2006 5:46:58 PM
Joe Van Dyk wrote:
> Mikito Harakiri wrote:
> > This is a culprit that OO people stubbornly refuse to understand.
> > Embedding high level language (SQL) statements inside low level
> > language (Java) is perfectly reasonable. What you propose instead, a
> > pathetic set of classes that build the query dynamically?
>
> I'm not sure what you mean by "a pathetic set of classes that build the
> query dynamically".  Are you referring to Object-Relational Mappers here?

Yes.

0
5/31/2006 5:51:25 PM
Joe Van Dyk wrote:
> frebe73@gmail.com wrote:
> >>I have certainly found systems that should NEVER use an RDBMS.  But I
> >>have never found a system that could not benefit from a good OO
> >>language.
> >
> >
> > But there are many (enterprise) applications there OOAD is not
> > suitable. Some OO languages (such as java) has disadvantages because
> > they don't allow first-order functions and function pointers.
>
> I don't know Java, but if your statement about Java disadvantages is
> true, that's a problem with Java -- not with OO.

It is simple, if not particularly convenient, to use what are
essentially
first-order functions and function pointers in Java. However,
the fact that you have to fake it illustrates why OOP is merely
a useful point of view that works a lot of the time, as opposed
to a true foundationally complete approach to programming.

Don't get me wrong; I really like OOP and it's what I use
when I need to program. But don't mistake its usefulness
for profundity. OOP has some deep problems, and some
of its features, like encapsulation and inheritance, will be
sloughed off when better techinques become widely available.


Marshall

0
5/31/2006 5:54:52 PM
Bob Badour wrote:
> Robert Martin wrote:
>
> > Finally, and this is critical to the understaning of my point, the code
> > in which data integrity is specified IS application code.  It may be
> > written in a special purpose DB language, or it may not.  But it is code
> > that supports the application.
>
> Code? Do you consider a well-formed formula code? Are logic predicates
> code? I am just curious what you define as code. If you define code to
> include everything, then your statement is true if unremarkable and
> uninteresting.

Another good catch.

A common misconception among application programmers
is that their technique of managing integrity with hand written
code protected by object encapsulation is the equal of
a centrally managed declarative integrity constraint, and
that it's merely six of one, half dozen of the other.

In fact, the reality is that the declarative integrity constraint
is at a higher level of abstraction, and is at a much lower
cost to produce and maintain, and at a much lower risk
for error, than the hand-written code.


Marshall

0
5/31/2006 6:03:21 PM
"Robert Martin" <unclebob@objectmentor.com> wrote in message
news:2006053107402343658-unclebob@objectmentorcom...

> There is a difference between data modeling and databases.  Data
> modeling is an important discipline that must be considered for every
> application.  A good data model is a critical part of a good system
> architecture and, along with the partitioning of behavior, is close to
> the core value of the system.
>

Agreed.

> A DBMS is a technical detail.  Decisions about it should be deferred as
> long as possible. The decision to use Oracle is NOT at the core of the
> system.  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.

Agreed, up to a point.   Choosing WHETHER to use a DBMS is a major decision,
although not quite like the data model.
Even if its postoponed as long as possible,  it's still going to be quite
early in the decision making process.

If one chooses to use a DBMS,  one can defer for a while deciding what class
of DBMS  (meaning, relational, codasyl, hierarchical, object oriented, or
sui generis) to use.  But by the time you come to logical data modeling,
you should be able to choose a model that fits well with the class of DBMS
you will use.  Even if you decide not to use a DBMS,  and instead use
indexed files,  you may find that the relational model suits you well for
logical data modeling.  Been there, done that.

Choosing a particular DBMS,  (Oracle, DB2, SQL Server, etc.)  can be
deferred even longer.  By the time you get down to physical data modeling,
you should have made this choice, as well as choices about resources,
volumes, traffic, and acceptable delay times.







0
dcressey (35)
5/31/2006 6:04:27 PM
"Robert Martin" <unclebob@objectmentor.com> wrote in message
news:2006053108160577923-unclebob@objectmentorcom...

> Actually, based on your post, I don't think you disagree completely
> with mine.  At most I think you disagree with the emphasis.  My "bucket
> of bits" statement is extreme because I am often found in the situation
> of helping teams of developers who start their projects by saying: "OK,
> we've got Oracle.  Now what?"


I, on the other hand,  have run into a lot of teams who say "we'll worry
about all that normalization crap when we're ready to start work on version
2."



0
dcressey (35)
5/31/2006 6:08:22 PM
Robert Martin wrote:
> On 2006-05-30 17:54:53 -0500, "Marshall" <marshall.spight@gmail.com> said:
> 
>> CMCC wrote:
>>
>>> Marshall wrote:
>>>
>>> I speak in terms of what he *seems to have written*. Somehow I have
>>> to refer to what it is I am talking about! And that is the subject of
>>> this thead.
>>
>> Grrrr. Okay, fine; I'll do the work. In the future if you have a
>> question
>> for me, it will be necessary to ask me the full actual question, and
>> not refer ambiguously to things written elsewhere.
>>
>> [scanning back through the thread ...]
>>
>> Okay, maybe you are asking about this:
>>
>>> No, a DBMS is a bucket of bits with some low level rules to manage
>>> those bits.  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.
>>> 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.  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.
>>
>> There are many different contexts in which software is developed.
>> I will speak relative to enterprise software, which is where DBMS
>> software is often found. In that context, the above quoted
>> paragraph is pure, unadulterated garbage. It is not simply
>> valueless; it is actively harmful. The writer furthermore
>> demonstrates that he completely lacks any understanding
>> of what the field of data management is, or what it is for,
>> or why it is useful.
> 
> Ah, it is so easy to generalize about what one person understands.
> Are you saying that it is "pure unadulterated garbage" that application 
> developers should isolate their application code from the the whims of 
> the API designers at Oracle?

If by API you mean SQL, then no, they shouldn't. If by API you mean some 
low-level interface between your OO language and the DBMS, then it might 
or might not make sense to wrap one low-level interface in another.


   Should those application designers use
> every little cute ORACLE trick and call?

Should they go out of their way to use features only available on 
Oracle? No. Should they spend days jumping through hoops to avoid them? No.


   Or shoudl they stick to
> standard SQL as proferred by ODBMS or JDBMS, etc.  Should those 
> application developers scatter embedded SQL all through their 
> application code?

Sure. The real question is: Should they scatter low-level languages like 
C++ or Java all through their application code?



   Or should they partition that application code into
> areas that know about the DB and areas that don't?

I don't see how that is relevant to any of the idiocy you have posted. 
One might partition applications any number of ways. Some will be better 
than others by various measures.


   Should they strive
> to make it possible to swap Oracle for MySql or not?

If you mean to replace MySql with Oracle, that's trivial. If you mean to 
replace a data management system with a file processor, that's generally 
rather stupid unless one is using so little data management that the 
cost of the swap is hardly noticeable in the first place.


   Should they strive
> even to eliminate the relational flavor of the data from the guts of 
> their algorithms, or not.

Eliminate relational flavor? That doesn't make any real sense on its 
face. Do you mean set algebra or predicate logic? In any case, they 
should strive to eliminate the stink of the lower level languages they 
find themselves stuck with and try to elevate their code as much as 
possible by using higher-level abstractions like relations.

Did effective abstraction cease to be a worthy design goal?


>> The reason why you see crap like this is because it is being
>> written by application developers. Application developers are
>> great at writing applications, but once they have success in
>> that one area, they overgeneralize and begin to believe that
>> their techniques are the correct techniques to apply to every
>> software development area. However this represents a
>> multi-decade regression in the field of data management.
> 
> I agree with some of this.  Much of this debate comes from one side not 
> understanding the position of the other, and overgeneralizing.

I agree. If you were not so ignorant, you wouldn't overgeneralize the 
way you do.


   However,
> I understand both sides quite wall,

Quite frankly, you are full of shit. As many others, who do understand 
both sides very well, have already noted, what you post is ignorant, 
stupid tripe. Your posts are incoherent on their face. One who 
understands 'both sides' doesn't post the sort of ridiculous nonsense 
you do.


  having done both and been resonsible
> for both, for damned near 35 years now.

And people actually paid you for it?!? That's sad. I guess you are proof 
of the adage that some people will get 35 years of experience while 
others will get one year of experience 35 times.


I also agree that my "pure
> unadulterated garbage" above was spoken from the point of view of an 
> application developer.

As an application developer, I note that it is pure unadulterated 
garbage from my perspective as well.


   The reason for that, of course, is that it was
> in response to database developers overgeneralizing their own point of 
> view.

I don't know what you responded to, but the incoherent drivel you wrote 
could only be written from a position of ignorance and stupidity.


>> Data management in the 1960s lacked any understanding
>> of the issues that the field has today. And if the application
>> programmers have their way, and the existing field of
>> data management is discarded, those same application
>> programmers will face all the same problems that the
>> programmers of the 1960s did, over again. And over
>> the decades, they'll build systems that tackle questions
>> like integrity enforcement, ad hoc queries, transaction
>> management, etc. Slowly, they will reinvent the field.
> 
> It is actually not a bad thing that one side is forced to reinvent the 
> other,  Indeed that may be the only way for the two sides to see 
> eye-to-eye.

As an application developer who understands the relational model, I have 
no problem seeing eye-to-eye with database designers and administrators. 
You flatter yourself if you think you have anything special to offer 
that database practitioners don't already understand better than you 
ever will.


   For, of course, the inverse operation is occurring on the
> other side of the divide.  Database application developers are slowly 
> learning what software application developers have fought long and hard 
> to learn over the last 30 years.

Slowly learning? That's laughable coming from someone as obviously 
ignorant and stupid as you are. The fact is, after more than 30 years of 
long hard struggle, the OO folks are nowhere near as advanced as the 
relational model was the year before you started your career.


   That coupling and cohesion matter, and
> that partitioning, data hiding, and isolation are necesary for large 
> applications.

Regardless whether using the algebra or the calculus, the relational 
model allows one to couple or decouple at will. Views are far more 
powerful for the dealing with the remainder of the issues you mention 
than anything the OO crowd have ever dreamt up.

The logical and physical independence of the relational model allow one 
to largely automate the task of managing the complexity that the above 
issues attempt to manage.


> Fortunately, there are groups like this one in which the two sides and 
> discuss the issues with each other.  So long as we can avoid calling 
> each other names, we might even be able to learn from each other.

Thus far, you lead me to suspect you have nothing to offer to anyone who 
understands the relational model, and your claim of 35 years working 
with it while posting such ridiculous nonsense leads me to suspect you 
are impervious to learning.


>> And, if they do so, it would be poetic justice if the
>> programmers being born today trash all their work
>> in favor of some new fad.
> 
> That poetry works in both directions.  I've seen an awful lot of 4gl 
> abortions, and deeply chagrined DB programmers over the years.

What you have never seen is a relational abortion. The clay feet of 4gl 
abortions have always been their 3gl roots.
0
bbadour (434)
5/31/2006 6:12:49 PM
Robert Martin wrote:

> On 2006-05-30 07:33:03 -0500, "Tony Andrews" <andrewst@onetel.com> said:
> 
>> Alfredo Novoa wrote:
>>
>>> Robert Martin wrote:
>>>
>>>> No, a DBMS is a bucket of bits with some low level rules to manage
>>>> those bits.  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.
>>>
>>>> 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.  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.
>>>
>>> If the mentors are like this, I don't want to imagine the rest.
>>
>> Considering the use of so many button-pushingly ludicrous statements
>> such as "a DBMS is a bucket of bits" and "swapped out for another at a
>> whim", do you not think perhaps Mr Martin was teasing (or goading) you?
> 
> I was doing neither.  I was expounding an attitude about DBMSs that I 
> have found useful over the years.

That you found it useful says more about your intellect than about DBMSs.
0
bbadour (434)
5/31/2006 6:13:47 PM
"Robert Martin" <unclebob@objectmentor.com> wrote in message
news:2006053108292037709-unclebob@objectmentorcom...
> On 2006-05-30 06:31:53 -0500, "Erwin" <e.smout@myonline.be> said:
>
> > Little point in preaching to the chuiar of course (how do you spell
> > that damn word ?).
> >
> > Go tell this on an Otherwise Oriented forum, you'll get dawnbashed.
> >
> > That said, application code is still highly important because it's
> > needed to fill all the holes that current dbms's still leave wide open
> > in the area of constraint enforcement.
>
> This statement is fascinating.  It takes the view that the majority of
> the system is DB and that application code simply fills the cracks.
> The DB represents the bricks and the application code is the mortar.
>

I think the validity of your point of view depends on whether you view the
database as belonging to a single application,
or whether multiple applications,  perhaps originally provided  by different
vendors,  collaborate with each other by using the same database to store
persistent data.

Most people who have worked in application development workshops assure me
that such a scenario is unheard of. on the other hand,  I assure you that,
when the ideas about enterprise databases were being developed in the 1960s
and 1970s,  this was at the heart of what a database was all about.  The
idea of embedding a "data bank"  (if you prefer that terminology) in a
single application would have struck them as quaint, bordering on absurd.


>


0
dcressey (35)
5/31/2006 6:14:41 PM
Mikito Harakiri wrote:

> Bob Badour wrote:
> 
>>Fowler is an idiot. Given two formal systems: one very powerful system
>>operating at the level of intent and the other very low-level system
>>obscuring intent, his solution is to cripple the powerful one down to
>>match low-level one.
> 
> This is kind of extreme statement. Reading Mr Fowler's "Refactoring"
> was a pleasant experience back in 97. I couldn't help exclaming "I
> should have written that!" Unfortunately, Fowler's recent voyage into
> data management area is disappointing.

I found what he wrote rather obvious and not too informative. It sounds 
like you found it rather obvious too. While 'idiot' might be too 
extreme, he is a lightweight at best.
0
bbadour (434)
5/31/2006 6:18:00 PM
Marshall wrote:

> Robert Martin wrote:
> 
>>On 2006-05-30 17:54:53 -0500, "Marshall" <marshall.spight@gmail.com> said:
>>
  I have tried to embody that myself,
> as an application programmer studying the ways of the RM
> at the Jedi Academy.

Marshall, I realise you were just trying to interject some geeky humor. 
However, I think you do more harm by associating a mathematical 
discipline with a cartoonish sci-fi religion than the humor is worth. 
You reinforce a very damaging and widespread prejudice that keeps people 
from learning, which is counterproductive to the gist of your point.
0
Bob
5/31/2006 6:28:10 PM
Marshall wrote:

> Bob Badour wrote:
> 
>>Robert Martin wrote:
>>
>>
>>>Finally, and this is critical to the understaning of my point, the code
>>>in which data integrity is specified IS application code.  It may be
>>>written in a special purpose DB language, or it may not.  But it is code
>>>that supports the application.
>>
>>Code? Do you consider a well-formed formula code? Are logic predicates
>>code? I am just curious what you define as code. If you define code to
>>include everything, then your statement is true if unremarkable and
>>uninteresting.
> 
> Another good catch.
> 
> A common misconception among application programmers
> is that their technique of managing integrity with hand written
> code protected by object encapsulation is the equal of
> a centrally managed declarative integrity constraint, and
> that it's merely six of one, half dozen of the other.
> 
> In fact, the reality is that the declarative integrity constraint
> is at a higher level of abstraction, and is at a much lower
> cost to produce and maintain, and at a much lower risk
> for error, than the hand-written code.

That covers the well-formed formula part, but my point goes even further 
than that. Most of what he refers to as application code simply derives 
new statements from the data, which is what a logic predicate would do.
0
bbadour (434)
5/31/2006 6:32:44 PM
Others have debunked a variety of areas in this post already but a few
bits caught my eye ...

Robert Martin wrote:
> This statement is fascinating.  It takes the view that the majority of
> the system is DB and that application code simply fills the cracks.
> The DB represents the bricks and the application code is the mortar.
>

Applications come and go. Languages come and go. Character interfaces
came and went. Client-server came and kind of went. Batch applications
made a bit of a come-back in nice new clothes as web apps. And guess
what ? The database is still there. Where would that suggest we expend
our efforts ?

> The application code is not the glue that fills in the cracks.  Instead
> the data is the cargo, and the application code is the railway network,
> engines, and cars, factories, that transform the raw data into useable
> product.  The databases are the warehouses, and a specific vendor's
> DBMS is the material that the warehouse is made of.
>

Hmmmm .... (I can guess where this is going ...)

> Granted those warehouses are complicated structures with their own
> internal access and transport mechanisms to put the data in and get the
> data out, and keep the data safe.  But they aren't the railway network,
> factories, and distribution networks.
>

Uh-huh ....

> ...  Frankly, it IS the responsibility of the application to enforce integrity.  Oh, the
> DB can enforce it while the data is in the warehouse, but the data
> comes out of the warehouse, gets transported all over the place, gets
> transformed in many different ways into many different products, gets
> presented to many different customers and put into many different
> systems, and for all these activities it is the APPLICATION that must
> enforce the integrity of the data.  The DB loses control once the data
> is out of the warehouse.
>

Oh fabbo ! Let's take the data, throw it around a network a bit for
processing, then throw it back around the network for storing it again
! Network bandwidth vendors must be rubbing their hands with glee at
this sort of thinking. The biggest performance black hole in a
networked application isn't the database, or the transaction log, or
the PC client, or the disk drives - it's that gnarly chunk of wire
running from the server to who knows where to wherever the client code
is, and back again. The more goes through that chunk of wire, the
slower things go. Better to leave the data exactly where it is for as
much of the time as possible.

Incidentally, how do you write batch applications ? You know, those
apps that deal with *lots* of data in one go ? Or do we only think
about interactive, or pseudo-interactive, applications nowadays ?

> Clearly keeping the integrity of the data in the warehouse is
> important.  But that's not the whole story.  It's not even most of the
> story.
>
> Finally, and this is critical to the understaning of my point, the code
> in which data integrity is specified IS application code.  It may be
> written in a special purpose DB language, or it may not.  But it is
> code that supports the application.
>

Integrity *must* be managed in the database. That way, any and every
application that uses that data gets a consistent view. Not just "the"
or "a" application - all of them. Including your shiny bespoke coded
application but also the GUI report writer, the Excel spreadsheet with
the ODBC link, the SQL terminal monitor session, and all the other
routes to seeing the data application programmers have a wee tendency
to forget about.

"Why are we seeing strange outputs on the reports ?"
"It seems someone updated some data without going through the
application, so we couldn't make sure they stuck to the rules."
"!!!"

Always remember kiddies - it's a bit like puppies.

"Databases are for life - applications are for Christmas."

So far as I'm concerned, the best applications I've seen have put all
the integrity, constraints, and heavy business logic in the database.
The front end took care of basic validation of input and organising
workflow. (And even then, because the front ends were in Java and the
file format "chosen" was XML, there seemed to be a lot of, from the
outside, unnecessary pushing and shoving going on out there.) But never
mind - we can replace the front end with .Net, or whatever comes next -
the important bits stay the same, tucked away in the database,
oblivious to the fads and fashions outside.

0
5/31/2006 6:44:06 PM
On 2006-05-31 09:32:34 -0500, "Marshall" <marshall.spight@gmail.com> said:

> Would you also say that the decision of whether to use an OOPL
> or an FPL is a detail? If your system does data management,
> then at the core of the system you should have a Data Base
> Management System. Not to use the tools best suited for
> the problem is irresponsible.

I certainly agree with the last part of that.  I'd also say that the 
decision not to use an OOPL had better be very well founded.  (e.g. 
like you are working in a DSP that has no OO compiler).

If you system does data management then you need some way to manage 
that data.  You also need some way to transform that data according to 
the application business rules.  Those to things are orthogonal and 
neither should have a strong impact upon the other.  Thus the fact that 
I have an RDB helping me to manage my data may be entirely irrelelvant 
to the system as a whole, except as the details data management 
mechanism.

I agree that there are some systems where the use of an RDB is an 
obvious choice; but that does not make it a core design decision. 
Morevoer I'd still want to hide the RDB from the application code as 
much as I could.
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 7:05:52 PM
On 2006-05-31 10:53:23 -0500, Bob Badour <bbadour@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.

> 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.  So for some application domains RDSBs work very 
poorly, and other mechanisms work much better.

> 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.  There are many data representations that can be useful and 
fruitful.  The oft touted formalism of RDBs is fine; but does not 
preclude other mechanisms.  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.
> 
> 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.  I agree that RDBs DO allow a technology 
independence.  However, they are not the only means to achieve this.  
Again, consider filesystems.  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.  Filesystems seem to be quite 
technology agnostic.
> 
> 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.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 7:17:58 PM
On 2006-05-31 13:04:27 -0500, "David Cressey" <dcressey@verizon.net> said:

> Agreed, up to a point.   Choosing WHETHER to use a DBMS is a major decision,
> although not quite like the data model.
> Even if its postoponed as long as possible,  it's still going to be quite
> early in the decision making process.

I agree that some application domains will force the issue earlier than 
others.  However, I have been able to defer that decision for very long 
times indeed.
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 7:23:32 PM
On 2006-05-31 08:10:16 -0500, frebe73@gmail.com said:

> 
> Why can't OO tools be deferred both in  time and space to be considered
> later and partitioned into a small segment of the code?

They can, but only if you have decided to write the bulk of the 
application code in the DB language.  And if you have done that, then 
you have really made your decision about the application language 
early.  And that was my point.  You can't defer the decision about the 
application language for very long.  You CAN defer the database 
decision, sometimes for a very long time indeed.
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 7:26:01 PM
Mikito Harakiri wrote:
> Joe Van Dyk wrote:
> 
>>Mikito Harakiri wrote:
>>
>>>Robert Martin wrote:
>>>
>>>
>>>>Application developers get into trouble when they DONT treat the
>>>>database as a detail.
>>>
>>>
>>>Robert, you claim 35 years of application programming experience. Have
>>>you ever come across a performance problem when database is accessed
>>>via API
>>>
>>>getItemIdList
>>>getItemDetail
>>>
>>>so that a single jsp page issued a hundred SQL statements instead of a
>>>single one? Come on, this one is so common that it surfaces on every
>>>performance meeting.
>>
>>This problem is easily solved via caching.
> 
> 
> Yep.
> 
> User: "I updated the stupid item, why didn't it refresh on the damn
> screen?"
> Programmer: "Fixing this problem requires to make the cache as
> sophisticated as DBMS. Not feasible in the current release".

Odd -- never had that problem.

Joe
0
joe.vandyk (160)
5/31/2006 7:31:11 PM
On 2006-05-31 08:10:16 -0500, frebe73@gmail.com said:

> But there are many (enterprise) applications there OOAD is not
> suitable. Some OO languages (such as java) has disadvantages because
> they don't allow first-order functions and function pointers.

If by "First order functions" you mean "blocks" or "Closures" then I'll 
happily agree with you.  Anonymous inner classes are a poor substitute. 
 If, on the other hand, you are just referring to regular global 
functions, then you are incorrect.  One can very simple create them in 
Java by making them a static method of a class named Global.

As for function pointers, that's what OO is really all about.  OO is a 
formalism that gives you function pointer capability without the 
"danger".  Anything you can do with a function pointer in C, I can do 
with polymorphism in Java.

-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 7:35:44 PM
On 2006-05-31 11:21:45 -0500, frebe73@gmail.com said:

>> I don't know Java, but if your statement about Java disadvantages is
>> true, that's a problem with Java -- not with OO.
> 
> In a true OO language there are no first order functions. Some OO
> languages, like Python, are a little more pragmatic and has some non-OO
> features too.

The fact that Java does not have global functions is annoying at worst. 
 They can be easily created as:

public class Global {
  public static void myFunction();
}


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 7:38:47 PM
On 2006-05-31 12:54:52 -0500, "Marshall" <marshall.spight@gmail.com> said:

> Don't get me wrong; I really like OOP and it's what I use
> when I need to program. But don't mistake its usefulness
> for profundity. OOP has some deep problems, and some
> of its features, like encapsulation and inheritance, will be
> sloughed off when better techinques become widely available.

I think you could make the same statements about any programming 
disciplines.  No tool is perfect.
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 7:39:58 PM
On 2006-05-31 11:09:05 -0500, "topmind" <topmind@technologist.com> said:

> I have not found a way to use "coupling and cohesion" as an objective
> metric.

I have.  Read my papers on the topic.

If module A depends on module B, then A is coupled to B.  If B canges a 
lot, then those changes impact upon A.  If A does not need to change, 
but is forced to change because of B, then we have coupling that we'd 
like to get rid of.  Creating an interface IAusesB that B implement and 
A uses isolates A from many of the changes to B.




-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 7:43:05 PM
Robert Martin wrote:

> On 2006-05-31 09:32:34 -0500, "Marshall" <marshall.spight@gmail.com> said:
> 
>> Would you also say that the decision of whether to use an OOPL
>> or an FPL is a detail? If your system does data management,
>> then at the core of the system you should have a Data Base
>> Management System. Not to use the tools best suited for
>> the problem is irresponsible.
> 
> I certainly agree with the last part of that.  I'd also say that the 
> decision not to use an OOPL had better be very well founded.  (e.g. like 
> you are working in a DSP that has no OO compiler).

Or you are working on an application that doesn't need to use a very 
large state machine or you need the competitive advantage offered by a 
more-powerful higher level language than the typical OO language.


> If you system does data management then you need some way to manage that 
> data.

Duh! And the best way we have to manage data is with a relational 
database management system.


   You also need some way to transform that data according to the
> application business rules.

Here, once again, you prove your ignorance and stupidity. The business 
rules are the business rules. One does not have a separate set of rules 
for applications from data. Everything has to meet the needs of the 
business.

Transforming data according to the business rules is best done as close 
to the level of intent as possible using the most powerful tools 
available for deriving data. Those tools are equivalently the relational 
algebra and the relational calculus.


   Those to things are orthogonal and neither
> should have a strong impact upon the other.

Ah, so you were just building a straw man all along. Yawn.


   Thus the fact that I have
> an RDB helping me to manage my data may be entirely irrelelvant to the 
> system as a whole, except as the details data management mechanism.

May be, but not bloody likely. Idiot.


> I agree that there are some systems where the use of an RDB is an 
> obvious choice; but that does not make it a core design decision. 
> Morevoer I'd still want to hide the RDB from the application code as 
> much as I could.

That's because you are stupid and ignorant. Repeating the above does 
nothing to change that.
0
bbadour (434)
5/31/2006 7:45:26 PM
Bob Badour wrote:
> Marshall wrote:
>
> > Robert Martin wrote:
> >
> >>On 2006-05-30 17:54:53 -0500, "Marshall" <marshall.spight@gmail.com> said:
> >>
>   I have tried to embody that myself,
> > as an application programmer studying the ways of the RM
> > at the Jedi Academy.
>
> Marshall, I realise you were just trying to interject some geeky humor.
> However, I think you do more harm by associating a mathematical
> discipline with a cartoonish sci-fi religion than the humor is worth.
> You reinforce a very damaging and widespread prejudice that keeps people
> from learning, which is counterproductive to the gist of your point.

Agreed. I withdraw the remark.

I do love my cheap humor.


Marshall

0
Marshall
5/31/2006 8:10:32 PM
Robert Martin wrote:

> On 2006-05-31 10:53:23 -0500, Bob Badour <bbadour@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.
0
bbadour (434)
5/31/2006 8:19:20 PM
On 2006-05-31 11:09:05 -0500, "topmind" <topmind@technologist.com> said:

> This sounds like the "RDBMS is a low-level tool/service" argument. I
> have to disagree. One can treat it merely as a filing system, but can
> also treat it as a sophisticated modeling tool.

Agreed.  You CAN use the RDBMS as the application programming language. 
 However, if you do that, then you have made the decision about 
application programming language.  You can't defer this decision very 
long.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 8:21:43 PM
On 2006-05-31 11:28:08 -0500, frebe73@gmail.com said:

> I am afraid you are not talking about JDBC/ADO/ODBC as an abstract
> interface. Making custom abstract interfaces for every application is a
> very clumsy an inefficient way to achieve vendor independence. If you
> don't think an interface such as JDBC gives you vendor independence,
> use another generic interface on top.

You get vendor indpendence with JDBC, ODBC.  What you don't get is 
independence from the relational model.  I want that too.  I don't want 
my application to have to know that there are tables here, and tables 
there, and relationship tables that bind them together.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 8:23:24 PM
Joe Van Dyk wrote:
> Mikito Harakiri wrote:
> >
> > Robert, you claim 35 years of application programming experience. Have
> > you ever come across a performance problem when database is accessed
> > via API
> >
> > getItemIdList
> > getItemDetail
> >
> > so that a single jsp page issued a hundred SQL statements instead of a
> > single one? Come on, this one is so common that it surfaces on every
> > performance meeting.
>
> This problem is easily solved via caching.

This is like saying: we have a big pile of dirt on our expensive
Persian rug; what shall we do? That problem is easily solved
by covering the dirt in a layer of palm fronds.

Caching certainly has its place in the set of tools used
to solve performance problems. And its place is exactly:
the tool of last resort. When everything else has failed,
you cache. I don't know why it's so often the *first* thing
that junior programmers come up with; maybe because
it's easy to understand, and solving the actual problem
requires some effort.

The *best* way to solve the performance problem that
Mikito describes is to rewrite the object-at-a-time code
into set-at-a-time code, which will necessarily perform
much faster. Unfortunately OOPLs encourage object-
at-a-time thinking, so it's hard for OO programmers to
learn this lesson. I try to repeat it at every team
meeting, which is not usually a problem because
somewhere in every meeting someone will propose
papering over a performance problem by caching.


Marshall

0
5/31/2006 8:25:24 PM
On 2006-05-31 08:04:41 -0500, frebe73@gmail.com said:

>> A DBMS is a tool, not an overarching philosophy, nor
>> the core of the system design.  A DBMS is a *mechanism* that can be
>> used to *implement* certain elements of the system design.
> 
> A DBMS is a tool. But the relational model is an overarching
> philosophy.

I agree with that.  However, the decision to use that philosophy can be 
defered, sometimes for a very long time.
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 8:30:17 PM
On 2006-05-31 08:43:29 -0500, Ed Kirwan <iamfractal@hotmail.com> said:

> (Shocked to read of the end of, "Software Development," UncleBob; just 
> as Enums were getting interesting, too.)

I've been thinking of continuing the Craftsman articles on my blog site:
www.butunclebob.com

-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
5/31/2006 8:44:31 PM
Robert Martin wrote:
> On 2006-05-30 07:51:15 -0500, "CMCC" <c_jackal@hotmail.com> said:
>
> > Robert Martin wrote:
> >> No, a DBMS is a bucket of bits with some low level rules to manage
> >> those bits.  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.
> >> 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.  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.
> >
> > No, a OO application is a bucket of bits with some low level rules to
> > manage
> > those bits.  An DBMS provides the beavior that the customer
> > wants to see.  We can completely eliminate the OO application and
> > replace it with
> > another of an entirely different form (non OO for example) and
> > still have all the business behavior we need.
> >
> > The people who sell OO applications have sold you, and the industry, a
> > misconception: that the OO application is the heart of the system.
> > This is
> > flawed.  The heart of the system is the DBMS.  The OO application
> > 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.
>
> Let this be a lesson to all you cowards who resort to ad-hominem
> attacks and name calling.  THIS post is a very good rebut to mine.  He
> actually used his BRAIN to invert my argument and throw it back in my
> face.  And he did it without calling me a fool, or an idiot, or a
> trickster.
>
> Carlos, I have to agree with everything you said.

I didn't said much, did I?
But... are you saying you agree with everything I said *and* everything
you said? Both visions are way apart.
Maybe this is a circle and very apart visions meet each other at one
point?


 From the
> data=modeler's point of view, the application is just a pile of
> behaiors.


  Applications will come and application will go, but the data
> structure will remain.  It may change.  It may grow.  But it will
> always be there!

Hold on to this one!

>
> And this brings us to the real issue at hand.  Each side views the
> other as a bucket of bits!  Is this an error?  Is this a flaw?  No!
> This is good software design!  It is the role of software design to
> abstract away the details.  From the point of view of the application,
> the database is a detail.  From the point of view of the data model the
> applications are details.  And that's the way it SHOULD be.

But above you say applications come and go.. and the data structure
will remain. It seems to me the data structure is quite a huge detail
and
applications little details then. I mean.. from the point of view of
the
whole system and with lots of time.....


>
> Application developers get into trouble when they DONT treat the
> database as a detail.
>

It's a huge detail because the DBMS is forcing on them the structure
of the data and the rules by which this data may or may not be changed
within that structure. And by rules I mean *all* the rules to which the

data, even derived data known to the DBMS, has to comply
(constraints, business , static, dynamic,  ... doesn't matter what
they are called)
The DBMS has to! With all this applications coming and going
someone has to take charge.

>
> Data modelers get into trouble when the DONT treat the applications as details.

They (with the DBMS)  have to provide an interface and deliver what
that interface
is promising. And secure the data. Requests from outside (god may know
how many applications are trying to 'store things' each with its own
view
of what the database should be doing for them) may change the database
*only*
to a new valid state (reachable through a valid state transition).

Maybe this is an acceptable analogy (not meant to be precise!):
The whole system is composed of the following:  ( MVC design pattern)
Database (Model)  Keeps its own state valid (the controller helps) no
matter what the
           applications (views) are asking.
DBMS (Controller) Provides an interface (SQL?) and controls
communications and a lot
        of other things (*checking rules*, transactions, concurrency..
whatever).
Applications (View) communicates about facts with users and from/to the
database 
through the controller.


Regards,
Carlos

0
c_jackal (9)
5/31/2006 9:15:22 PM
Marshall wrote:

> Bob Badour wrote:
> 
>>Robert Martin wrote:
>>
>>>Granted, granted.  But destroying the data is not the same as isolating
>>>the data management mechanism from the data model.
>>
>>More ignorant tripe. Do you even have a clue what a data model is? What
>>sort of data model you are talking about? Without that, what you wrote
>>is not only wrong but essentially meaningless.
> 
> Wow, I missed that one completely. "Isolate the data management
> mechanism from the data model." How in tarnation is the data
> manager doing to manage the data if it is isolated from the
> data model?

We human beings are wired to make sense of everything we experience. As 
a result, it takes considerable discipline even to recognise and to 
acknowledge incoherent nonsense.

In a sense, the nonsensical and the totally irrelevant are don't care 
conditions as far as natural selection goes. Making sense of nonsense 
and finding relationships among the unrelated impose no selective costs. 
Failing to make sense of a danger (getting eaten) or of an opportunity 
(starving needlessly) can impose a significant selective cost. Thus, we 
evolved to make sense of things quickly regardless whether it makes 
sense to make sense in the first place.

One can easily verify this by repeatedly selecting two words at random 
from the dictionary and asking oneself what are the relationships 
between the words. One's mind will almost always come up with a few.

When confronted with a nonsense sentence like the one above, humans will 
internally edit the sentence into one that makes sense. When you first 
read the sentence, I am sure your mind made minor substitutions of 
meanings until it meant something to you, and you didn't notice the lack 
of meaning. Other readers will make other substitutions until it makes 
sense to them; even though, it might mean something different when finished.

This is a human characteristic that brushes up against both Dijkstra's 
comments on elixirs and Date's _Principle of Incoherence_. It works very 
much in the favor of self-aggrandizing ignorants.

Here in Canada, we recently had a Prime Minister who so badly butchered 
his mother tongue as well as our other official language that the news 
media habitually reported what they thought he meant instead of what he 
actually said--even when purporting to quote him.

It takes discipline and work to read things as carefully as one would 
read a requirements document, a functional specification, a detailed 
design or a program's source-code looking for errors, but often that is 
exactly how one must read. It also helps to train one's mind to 
recognize the various forms of sophistry and of fallacious reasoning.

Even then, one is fighting an uphill battle.


>>Sadly, I have been paid large sums of money to fix the problems created
>>when teams started with "We've got objects. Woo hoo!" instead.
> 
> LOL! The "Woo hoo" really makes it.

Thank you. I wish it were included solely for humor and not as an 
accurate description as it was on some occasions. D'Oh!
0
bbadour (434)
5/31/2006 9:17:31 PM
Bruno Desthuilliers wrote:

> Marshall a �crit :
> 
>> Joe Van Dyk wrote:
>>
>>> frebe73@gmail.com wrote:
>>>
>>>> But there are many (enterprise) applications there OOAD is not
>>>> suitable. Some OO languages (such as java) has disadvantages because
>>>> they don't allow first-order functions and function pointers.
>>>
>>> I don't know Java, but if your statement about Java disadvantages is
>>> true, that's a problem with Java -- not with OO.
>>  
>> It is simple, if not particularly convenient, to use what are
>> essentially
>> first-order functions and function pointers in Java. However,
>> the fact that you have to fake it illustrates why OOP is merely
>> a useful point of view that works a lot of the time, as opposed
>> to a true foundationally complete approach to programming.
> 
> Have mercy, stop confusing Java with OO. I do OO everyday, and could not 
> live without HOFs.

Bruno, the fact that some OO has HOFs and some OO does not supports 
Marshall's observation. Adding a specific powerful feature to a language 
does not make it foundationally complete.


>> Don't get me wrong; I really like OOP and it's what I use
>> when I need to program. But don't mistake its usefulness
>> for profundity. OOP has some deep problems, and some
>> of its features, like encapsulation and inheritance, will be
>> sloughed off when better techinques become widely available.
> 
> Dynamic typing + real support for automatic (yet controlable) 
> delegation, and you don't need inheritance no more (still can use it  - 
> as an implementation detail - when it's convenient).

Are you agreeing with Marshall that encapsulation and inheritance are 
unecessary? Or are you suggesting that one should mistake whatever 
usefulness one finds in OO for profundity after all?


> wrt/ encapsulation, I'm afraid you're confusing it with data-hiding, 
> which is not a necessary pain if you have support for computed attributes.
> 
> What about ditching Java in favor of an OO language ?-)

What about ditching an ad-hoc computational model introduced for 
creating large unpredictable state machines out of small predictable 
state machines with predicate logic itself?
0
bbadour (434)
5/31/2006 10:06:05 PM
Robert Martin wrote:

> On 2006-05-30 16:08:14 -0500, "David Cressey" <dcressey@verizon.net> said:
> 
>> I think you have to solve the problem of defining a meaningful and useful
>> OODBMS without reference to the relational model.
> 
> While I think OODBs can be useful tools,

When I first read that sentence, I mistook tools for fools. It read 
better that way.

[meaningless gibberish snipped]
0
bbadour (434)
5/31/2006 10:20:32 PM
Joe Van Dyk wrote:

> Mikito Harakiri wrote:
> 
>> Robert Martin wrote:
>>
>>> Application developers get into trouble when they DONT treat the
>>> database as a detail.
>>
>>
>>
>> Robert, you claim 35 years of application programming experience. Have
>> you ever come across a performance problem when database is accessed
>> via API
>>
>> getItemIdList
>> getItemDetail
>>
>> so that a single jsp page issued a hundred SQL statements instead of a
>> single one? Come on, this one is so common that it surfaces on every
>> performance meeting.
> 
> This problem is easily solved via caching.

You hope, but if one nests the above type of construct, even caching may 
not save one.
0
bbadour (434)
5/31/2006 10:36:06 PM
Bruno Desthuilliers wrote:

> Bob Badour a �crit :
> 
>> Bruno Desthuilliers wrote:
>>
>>> Marshall a �crit :
>>>
>>>> Joe Van Dyk wrote:
>>>>
>>>>> frebe73@gmail.com wrote:
>>>>>
>>>>>> But there are many (enterprise) applications there OOAD is not
>>>>>> suitable. Some OO languages (such as java) has disadvantages because
>>>>>> they don't allow first-order functions and function pointers.
>>>>>
>>>>> I don't know Java, but if your statement about Java disadvantages is
>>>>> true, that's a problem with Java -- not with OO.
>>>>  
>>>> It is simple, if not particularly convenient, to use what are
>>>> essentially
>>>> first-order functions and function pointers in Java. However,
>>>> the fact that you have to fake it illustrates why OOP is merely
>>>> a useful point of view that works a lot of the time, as opposed
>>>> to a true foundationally complete approach to programming.
>>>
>>> Have mercy, stop confusing Java with OO. I do OO everyday, and could 
>>> not live without HOFs. 
>>
>> Bruno, the fact that some OO has HOFs and some OO does not supports 
>> Marshall's observation.
> 
> You don't get it : what I'm saying is that Java is *not* an OO language !-)

Yes, I understood that perfectly. However, it is an OO language as are a 
number of other OO language that lack HOFs. By your definition Simula 
would cease to be an OO language, which is absurd.

One does not build a sound foundation by the ad-hoc addition of features.


>>>> Don't get me wrong; I really like OOP and it's what I use
>>>> when I need to program. But don't mistake its usefulness
>>>> for profundity. OOP has some deep problems, and some
>>>> of its features, like encapsulation and inheritance, will be
>>>> sloughed off when better techinques become widely available.
>>>
>>> Dynamic typing + real support for automatic (yet controlable) 
>>> delegation, and you don't need inheritance no more (still can use it  
>>> - as an implementation detail - when it's convenient).
>>
>> Are you agreeing with Marshall that encapsulation and inheritance are 
>> unecessary?
> 
> Please stop confusing encapsulation with data-hiding.

Since I am unaware that I ever made that mistake in the first place, I 
find your command absurd.


  What I'm saying is
> that data-hiding is not necessary, and that only declarative static 
> typing and lack of support for delegation makes inheritance so 
> over-abused in brain-dead languages like Java.

The truth of the matter is that while data-hiding may not be necessary, 
information-hiding is a very sound engineering technique justified by 
the principle of the separation of concerns.

As for the rest, you are only adding further support to Marshall's 
observation that OO falls short of providing anything resembling a sound 
foundation to programming.


>> Or are you suggesting that one should mistake whatever usefulness one 
>> finds in OO for profundity after all?
> 
> Not feeding that troll.

Don't starve yourself on my account.


>>> wrt/ encapsulation, I'm afraid you're confusing it with data-hiding, 
>>> which is not a necessary pain if you have support for computed 
>>> attributes.
>>>
>>> What about ditching Java in favor of an OO language ?-)
>>
>> What about ditching an ad-hoc computational model introduced for 
>> creating large unpredictable state machines out of small predictable 
>> state machines with predicate logic itself?
> 
> What about functional programming then ?

What about it? Are you proposing either the typed or untyped lambda 
calculus as a replacement for predicate calculus for the foundation for 
data management? Or are you suggesting the typed lambda calculus as 
providing a complete foundation to programming in a manner similar to 
the foundation predicate calculus provides to data management? If the 
latter, what about concurrency?
0
bbadour (434)
5/31/2006 11:11:14 PM
"Bob Badour" <bbadour@pei.sympatico.ca> wrote in message 
news:cTmfg.15645$A26.364501@ursa-nb00s0.nbnet.nb.ca...
> Robert Martin wrote:
>
>> So for some application domains RDSBs work very
>> poorly, and other mechanisms work much better.
>
....
> You are stupid and ignorant, and your intellectual dishonesty accounts 
> well for both. Your responses are pointless.
>

Bob, I think you'd be on a somewhat stronger footing if you asked RCM for 
some examples of application domains that didn't lend themselves to RDBMSs, 
and then picked them apart, if you could.  Stop shaking your head, and 
argue.

Regards,
Daniel Parker

"When Peter talks about Paul, we learn more about Peter than we do about 
Paul."

-- Spinoza 


0
Daniel
5/31/2006 11:46:15 PM
Daniel Parker wrote:

> "Bob Badour" <bbadour@pei.sympatico.ca> wrote in message 
> news:cTmfg.15645$A26.364501@ursa-nb00s0.nbnet.nb.ca...
> 
>>Robert Martin wrote:
>>
>>>So for some application domains RDSBs work very
>>>poorly, and other mechanisms work much better.
>>
> ...
> 
>>You are stupid and ignorant, and your intellectual dishonesty accounts 
>>well for both. Your responses are pointless.
> 
> Bob, I think you'd be on a somewhat stronger footing if you asked RCM for 
> some examples of application domains that didn't lend themselves to RDBMSs, 
> and then picked them apart, if you could.  Stop shaking your head, and 
> argue.

With all due respect, Daniel, RCM has not raised to the level of an 
argument. He is only a waste of time, which is why I plonked him.

Why would I go to all of the work of pretending that comparing 
mechanisms with formalisms has any point at all?!? Did you not read 
anything of what I wrote?
0
bbadour (434)
6/1/2006 12:26:08 AM
> > What about functional programming then ?
>
> What about it? Are you proposing either the typed or untyped lambda
> calculus as a replacement for predicate calculus for the foundation for
> data management? Or are you suggesting the typed lambda calculus as
> providing a complete foundation to programming in a manner similar to
> the foundation predicate calculus provides to data management? If the
> latter, what about concurrency?

I would suggest the latter. In the RDBMS field I would want to use a
functional language as the language for implementing operators for new
data types (and indeed any other "code" that would be embedded in the
database). In that particular case, concurrency probably doesn't matter
for much. For areas where concurrency does matter, Concurrent Haskell
(Simon Peyton Jones et al, pp 295 - 308, Proceedings POPL '96, ACM)
would be a starter for ten; for a case study in concurrent programming
in Haskell, see "Developing a high-performance web server in Concurrent
Haskell" by Simon Marlow in Journal of Functional Programming,
12(4+5):359--374, July 2002 (also available from the haskell.org web
site).

0
6/1/2006 12:35:40 AM
Alfredo Novoa wrote:

> Marshall ha escrito:
> 
> 
>>Bob Badour wrote:
>>
>>>Alfredo Novoa wrote:
>>>
>>>
>>>>If the mentors are like this, I don't want to imagine the rest.
>>>
>>>Ugh. Alfredo, why did you have to ruin my evening? The ignorance and
>>>stupidity is astounding, isn't it?
>>
>>[removed comp.object]
>>
>>Agreed.
> 
> Marshall, I crossposted the thread looking for support for his public
> debunking (he is a sort of authority in the OO world), and it worked
> very well :-)
> 
> Thanks to the group!

In other words, you went over to comp.object to stir shit and suckered 
the rest of us into taking care of business for you.

Gee thanks. ;)
0
Bob
6/1/2006 12:45:30 AM
frebe73@gmail.com a �crit :
>>I don't know Java, but if your statement about Java disadvantages is
>>true, that's a problem with Java -- not with OO.
> 
> 
> In a true OO language there are no first order functions. 

Ho, really ?

I'm afraid your confusing OO (ie: *object* oriented) with 
"class-oriented" (like in Java). In a "true OO language", *everything* 
is an object. So functions are objects too. So functions are first-order.

> Some OO
> languages, like Python, are a little more pragmatic and has some non-OO
> features too.

Same remark here. Python as first-order functions because Python's 
functions *are* objects - and FWIW, you can turn any object into a 
callable by overlading the call operator.



0
6/1/2006 12:50:54 AM
Robert Martin a �crit :
> On 2006-05-31 11:21:45 -0500, frebe73@gmail.com said:
> 
>>> I don't know Java, but if your statement about Java disadvantages is
>>> true, that's a problem with Java -- not with OO.
>>
>>
>> In a true OO language there are no first order functions. Some OO
>> languages, like Python, are a little more pragmatic and has some non-OO
>> features too.
> 
> 
> The fact that Java does not have global functions is annoying at worst. 

Fredrik was not talking about having or not having functions but about 
the fact that Java's method are not objects. Which means you don't have 
  HOF. Which is a king-size PITA - like almost anything else in Java FWIW.
0
6/1/2006 12:55:38 AM
Marshall a �crit :
> Joe Van Dyk wrote:
> 
>>frebe73@gmail.com wrote:
>>>
>>>But there are many (enterprise) applications there OOAD is not
>>>suitable. Some OO languages (such as java) has disadvantages because
>>>they don't allow first-order functions and function pointers.
>>
>>I don't know Java, but if your statement about Java disadvantages is
>>true, that's a problem with Java -- not with OO.
>  
> It is simple, if not particularly convenient, to use what are
> essentially
> first-order functions and function pointers in Java. However,
> the fact that you have to fake it illustrates why OOP is merely
> a useful point of view that works a lot of the time, as opposed
> to a true foundationally complete approach to programming.

Have mercy, stop confusing Java with OO. I do OO everyday, and could not 
live without HOFs.

> Don't get me wrong; I really like OOP and it's what I use
> when I need to program. But don't mistake its usefulness
> for profundity. OOP has some deep problems, and some
> of its features, like encapsulation and inheritance, will be
> sloughed off when better techinques become widely available.

Dynamic typing + real support for automatic (yet controlable) 
delegation, and you don't need inheritance no more (still can use it  - 
as an implementation detail - when it's convenient).

wrt/ encapsulation, I'm afraid you're confusing it with data-hiding, 
which is not a necessary pain if you have support for computed attributes.

What about ditching Java in favor of an OO language ?-)
0
6/1/2006 1:02:17 AM
Robert Martin wrote:
> On 2006-05-31 10:53:23 -0500, Bob Badour <bbadour@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.
> 
>> 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.  So for some application domains RDSBs work very 
> poorly, and other mechanisms work much better.
> 
>> 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.  There are many data representations that can be useful and 
> fruitful.  The oft touted formalism of RDBs is fine; but does not 
> preclude other mechanisms.  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.
> 
>>
>> 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.  I agree that RDBs DO allow a technology 
> independence.  However, they are not the only means to achieve this.  
> Again, consider filesystems.  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.  Filesystems seem to be quite 
> technology agnostic.

Using file systems to make your point is a very poor choice.  Take a 
file, copy it over there.  Identical content, different paths.  Which
is "real?"  Which is a copy?   Which one should I modify if I want
my changes to persist?  How do Suzie and Bob and Joey and Ron know
which is the one I scribbled in?  What's keeping track of that?  A
file system?  No way!

These, and other, questions become de minimis in the relational model.

>>
>> 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.
> 
> 
0
jdavitt (12)
6/1/2006 1:48:55 AM
Bob Badour a �crit :
> Bruno Desthuilliers wrote:
> 
>> Marshall a �crit :
>>
>>> Joe Van Dyk wrote:
>>>
>>>> frebe73@gmail.com wrote:
>>>>
>>>>> But there are many (enterprise) applications there OOAD is not
>>>>> suitable. Some OO languages (such as java) has disadvantages because
>>>>> they don't allow first-order functions and function pointers.
>>>>
>>>>
>>>> I don't know Java, but if your statement about Java disadvantages is
>>>> true, that's a problem with Java -- not with OO.
>>>
>>>  
>>> It is simple, if not particularly convenient, to use what are
>>> essentially
>>> first-order functions and function pointers in Java. However,
>>> the fact that you have to fake it illustrates why OOP is merely
>>> a useful point of view that works a lot of the time, as opposed
>>> to a true foundationally complete approach to programming.
>>
>>
>> Have mercy, stop confusing Java with OO. I do OO everyday, and could 
>> not live without HOFs. 
> 
> Bruno, the fact that some OO has HOFs and some OO does not supports 
> Marshall's observation.

You don't get it : what I'm saying is that Java is *not* an OO language !-)

>>> Don't get me wrong; I really like OOP and it's what I use
>>> when I need to program. But don't mistake its usefulness
>>> for profundity. OOP has some deep problems, and some
>>> of its features, like encapsulation and inheritance, will be
>>> sloughed off when better techinques become widely available.
>>
>>
>> Dynamic typing + real support for automatic (yet controlable) 
>> delegation, and you don't need inheritance no more (still can use it  
>> - as an implementation detail - when it's convenient).
> 
> 
> Are you agreeing with Marshall that encapsulation and inheritance are 
> unecessary?

Please stop confusing encapsulation with data-hiding. What I'm saying is 
that data-hiding is not necessary, and that only declarative static 
typing and lack of support for delegation makes inheritance so 
over-abused in brain-dead languages like Java.

> Or are you suggesting that one should mistake whatever 
> usefulness one finds in OO for profundity after all?

Not feeding that troll.

> 
>> wrt/ encapsulation, I'm afraid you're confusing it with data-hiding, 
>> which is not a necessary pain if you have support for computed 
>> attributes.
>>
>> What about ditching Java in favor of an OO language ?-)
> 
> 
> What about ditching an ad-hoc computational model introduced for 
> creating large unpredictable state machines out of small predictable 
> state machines with predicate logic itself?

What about functional programming then ?
0
6/1/2006 2:00:22 AM
Robert Martin wrote:
> On 2006-05-30 06:31:53 -0500, "Erwin" <e.smout@myonline.be> said:
> 
>> Little point in preaching to the chuiar of course (how do you spell
>> that damn word ?).
>>
>> Go tell this on an Otherwise Oriented forum, you'll get dawnbashed.
>>
>> That said, application code is still highly important because it's
>> needed to fill all the holes that current dbms's still leave wide open
>> in the area of constraint enforcement.
> 
> 
> This statement is fascinating.  It takes the view that the majority of 
> the system is DB and that application code simply fills the cracks.  The 
> DB represents the bricks and the application code is the mortar.
> 
> I disagree with this analogy.  The RDBMS is a mechanisms for storing, 
> accessing, reporting, data.  That mechanism can be implemented many 
> different ways and need not even be an RDB.  The application code 
> defines what the program does with the data.
> 
> Some RDBMSs have created an application language in which some 
> application programs can be written.  (stored procedures in SQL, or 4th 
> gls, etc.)  Typically these langauges are very special purpose and 
> vendor specific.  They are not general purpose application programming 
> languages.  Therefore, though they have their uses, they should be used 
> with caution and restraint.
> 
> Even when such language exist, they are not part of the datbase itself. 
> They are still aplication languages.
> 
> The application code is not the glue that fills in the cracks.  Instead 
> the data is the cargo, and the application code is the railway network, 
> engines, and cars, factories, that transform the raw data into useable 
> product.  The databases are the warehouses, and a specific vendor's DBMS 
> is the material that the warehouse is made of.
> 
> Granted those warehouses are complicated structures with their own 
> internal access and transport mechanisms to put the data in and get the 
> data out, and keep the data safe.  But they aren't the railway network, 
> factories, and distribution networks.
> 
>>
>> Little true story : some OO proponent in a seminar (well, it was
>> actually "in front of an audience") declared that integrity enforcement
>> is the responsibility of the application, blahblahblah (he also
>> promoted meaningless ID's everywhere in the same breath).  I asked him
>> if he was actually aware that the first letter of the word IT stood for
>> "information".  His reply was : Yes, but the second stands for
>> "technology".
> 
> 
> The story may be true, but I'm not sure I get the point.  Frankly, it IS 
> the responsibility of the application to enforce integrity.  Oh, the DB 
> can enforce it while the data is in the warehouse, but the data comes 
> out of the warehouse, gets transported all over the place, gets 
> transformed in many different ways into many different products, gets 
> presented to many different customers and put into many different 
> systems, and for all these activities it is the APPLICATION that must 
> enforce the integrity of the data.  The DB loses control once the data 
> is out of the warehouse.
> 
> Clearly keeping the integrity of the data in the warehouse is 
> important.  But that's not the whole story.  It's not even most of the 
> story.
> 
> Finally, and this is critical to the understaning of my point, the code 
> in which data integrity is specified IS application code.  It may be 
> written in a special purpose DB language, or it may not.  But it is code 
> that supports the application.

An important clarification is needed here: when relational theory
advocates talk about data integrity they are talking about constraints
which are expressed in declarative language.  The superiority of
declarative v. imperative languages has long been decided.  In part,
data dogs slam OO languages because they are, essentially, procedural,
and building systems using them is extremely difficult.  Sure, you can
settle upon "design patterns" and conventions which help all the parts
fit together, but complexity abounds and the pile of code is littered
with artifacts which exist only because of the technology chosen.

Moreover, putting any part of the mechanism which ensures data integrity
in "the application" limits the currency of data -- and that's not
something those in the data business want to give up.
0
jdavitt (12)
6/1/2006 2:09:29 AM
Joe Van Dyk wrote:
> Mikito Harakiri wrote:
> 
>> Robert Martin wrote:
>>
>>> Application developers get into trouble when they DONT treat the
>>> database as a detail.
>>
>>
>>
>> Robert, you claim 35 years of application programming experience. Have
>> you ever come across a performance problem when database is accessed
>> via API
>>
>> getItemIdList
>> getItemDetail
>>
>> so that a single jsp page issued a hundred SQL statements instead of a
>> single one? Come on, this one is so common that it surfaces on every
>> performance meeting.
> 
> 
> This problem is easily solved via caching.

Caching?  Do you mean replicating part of the database in structures 
held in -- let me guess the term -- the data access layer?

> Joe
> 
0
jdavitt (12)
6/1/2006 2:36:42 AM
> You get vendor indpendence with JDBC, ODBC.  What you don't get is
> independence from the relational model.  I want that too.  I don't want
> my application to have to know that there are tables here, and tables
> there, and relationship tables that bind them together.

I think we already agree that the relational model is not a detail. So
why don't you want your application to know that there are tables here?

Fredrik Bertilsson
http://frebe.php0h.com

0
frebe73 (444)
6/1/2006 4:07:22 AM
Bruno Desthuilliers wrote:
> frebe73@gmail.com a =E9crit :
>
> I'm afraid your confusing OO (ie: *object* oriented) with
> "class-oriented" (like in Java). In a "true OO language", *everything*
> is an object. So functions are objects too. So functions are first-order.

Java is object oriented by any reasonable definition of the term.

Your claim about "*everything* is an object" and therefore in an
OOPL, functions must be objects, is not valid. It is not the
case that *everything* in an OOPL is an object. Is a comment
an object? Is private or public an object? Is a field an
object? No.

OOPLs have methods. There is no requirement to have
functions be objects to qualify an as OOPL.


Marshall

0
6/1/2006 6:36:38 AM
On Thu, 01 Jun 2006 01:48:55 GMT, J M Davitt wrote:

> Using file systems to make your point is a very poor choice.  Take a 
> file, copy it over there.  Identical content, different paths.  Which
> is "real?"  Which is a copy?   Which one should I modify if I want
> my changes to persist?  How do Suzie and Bob and Joey and Ron know
> which is the one I scribbled in?  What's keeping track of that?  A
> file system?  No way!

Let you have copied an INTEGER from one table to another. Which one is
real?
 
(None, both are integers! (:-))

> These, and other, questions become de minimis in the relational model.

It is strange to hear talks about identity from RM side. I thought RM
overcame that disease. There is no identity. Files are same, neither is
real. Paths aren't same. Identity is a relation, isn't it? Now if you'd
consider objects like (path,file), these could have identity defined as
id((path,file))=path.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/1/2006 8:02:16 AM
On Thu, 01 Jun 2006 02:50:54 +0200, Bruno Desthuilliers wrote:

> I'm afraid your confusing OO (ie: *object* oriented) with 
> "class-oriented" (like in Java). In a "true OO language", *everything* 
> is an object. So functions are objects too. So functions are first-order.

I don't think it could be consistent to have everything an object. Though
it is possible to have object corresponding to functions.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/1/2006 8:10:37 AM
"David Cressey" <dcressey@verizon.net> wrote in message 
news:2v2fg.8$Eo3.0@trndny02...

> "Cimode" <cimode@hotmail.com> wrote in message
> news:1149017607.537595.320820@i40g2000cwc.googlegroups.com...

>> Sorry the subject is "Possible bridges between OO programming
>> proponents and relational model"  .

> OK,  back to the topic...

> So far,  I've seen several attempts to project the world of objects onto 
> the
> world of (persistent) relations.  A table row
> contains the "shadow" of an object,  projected onto the world of data.

> This sounds like the easy way to go,  because the problem of producing a
> decent DBMS based on the relational model has been extensively studied, 
> and
> according to some, actually implemented.

> But I think it's upside down.

> I think you have to solve the problem of defining a meaningful and useful
> OODBMS without reference to the relational model.  You have to have the
> things you would want in a DBMS,  like backups, transactions, concurrency
> management,  etc.  You might even be able to acheive a certain measure of
> physical data independence.  Logical data independence is probably too
> ambitious a goal, without reference to the RM.

1. We have to have the means to identify the things in the repository that 
we wish
to manipulate. We know that prepositional/predicate logic, set theory etc is 
a
very powerful means of expressing that identification.

2. We would like the repository to be able to be persistent.

3. We would like the ability to change where appropriate, the physical 
representation
of the repository and/or the things in it, in order to improve system 
operation (the
storage size of 2, the execution speed of 1 etc) .

4. We would like the means to control concurrent access to things in the 
repository
(transactions etc) .


We need 1-4 regardless of whether we are using an SQL product, or an OODB.

The big problem with the OO model is that some of the properties of an 
entity in
the repository can be *behaviour* and not mere data items. So to combine the
best of the SQL world with that of the OO world, we need to have a model
where behaviour and data can exist interchangeably.

The paradigm that IMHO best allows that interchangeability is Functional
Programming. FP is quite a cultural move though from embedded SQL, C++
OODBs etc.


Regards,
Steven Perryman 


0
S
6/1/2006 8:17:04 AM
On Thu, 01 Jun 2006 02:09:29 GMT, J M Davitt wrote:

> An important clarification is needed here: when relational theory
> advocates talk about data integrity they are talking about constraints
> which are expressed in declarative language.

Yes. The language of constraints is declarative, but that does not make the
whole programming language 100% declarative.

> The superiority of
> declarative v. imperative languages has long been decided.

Where that follows from? Who and when has decided?

Concerning constraints, you wouldn't need any, in a purely declarative
language. Constraint limits space where an imperative action can be taken.

> In part,
> data dogs slam OO languages because they are, essentially, procedural,
> and building systems using them is extremely difficult.

I'd like to see some proof. In my personal, limited, ignorant, etc
experience domain-oriented languages are in order of magnitude worse than
worst OOPLs (like C++, for example). Practically all our customers start
with some sort of domain-oriented language, be it SQL, Simulink etc. Yes,
they get first 20% of functional requirements very quickly. Then, they
discover that the rest cannot be made at any cost, that maintenance is a
disaster, that non-functional requirements is what they should forever
forget of. Our job is basically to throw all that domain-oriented rubbish
away. Gradually, slowly, so that the customer wouldn't see it. In five
years or so he gets a working system with 5% or less legacy code.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/1/2006 8:47:48 AM
frebe73@gmail.com wrote:
> > Decoupling is good, if done at an appropriate level.  However, given
> > your preference for swapping out DBMSs "at a whim" you clearly have no
> > choice but to use the lowest common denominator abilities of all DBMSs
> > that might be chosen, which probably amounts to some very simple
> > low-level DML and SELECT statements.  Then you effectively build your
> > own pseudo-DBMS on top of this with application code.  What a waste of
> > time and effort, not to mention the money you spent buying a DBMS of
> > which you refuse to use 95% of the power!
>
> This is simply not true. I have been converting a major enterprise
> application from Informix to also support Oracle and SQL Server. I
> think that we had to rewrite less than 5% of the SQL statements. In
> almost every case we were able to use the same query for all vendors
> without changing the semantics of the original query. In some severe
> cases we had to "wash" the SQL statement using simple find/replace
> functions, to fit different vendors. The conclusion was obvious:
> Continue to embedd (ANSI) SQL in the application, but make your own
> (JDBC/ODBC/ADO) driver on top of the vendor driver, to eliminate the
> remaining incompatibilites between vendors.

Fair enough.  But in that case you have at least committed to using a
SQL DBMS, and that it will be from one of the major players in the
market.  That is somewhat different from RCM's position, which is (as I
understand it) that it should be trivial to unplug your SQL DBMS and
replace it by something else that doesn't even use SQL.

0
andrewst1 (87)
6/1/2006 9:31:27 AM
Thanks for the guidance...I will keep in mind your advice to give more
targetted questions...The subject would be to find out how and what OO
mechanisms (nice definition) can contribute to build better
implementations of relational requirements throughout the system life
cycle...

Questions I would like to discuss are of the following type:

> What are the available OO languages that can do a better job than SQL into handling data definition and manipulation...Java?
> What are the limitations of these languages to do what's above? What's currently missing in OO (Is object "persistence" a desperate attempt at establishing representations of R Tables)

My point is to help establish a practical list of feature (some kind of
Bill of Material) of important requirements OO languages should meet to
be potential candidates to better allow relational implementation.  I
do believe this kind of debate can be more useful that raw opposition
between programmers and relational advocates.  As you stated, OO can in
no case be put on the same standpoint than relational model as they are
of  totally different nature...In a schematic manner, it seems OO is
more about implementation than abstraction only a model can bring.  It
also seems to me OO mechanisms could do as well as current SQL (at
least its current form) into implementing better DBMS... Question is
how?

Thank you for helping into that direction...
Here is the thread

http://groups.google.com/group/comp.databases.theory/browse_thread/thread/54e82593b205a2a8

Bob Badour wrote:
> Cimode wrote:
>
> > Hello,
> >
> > 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 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.
>
> Cimode, the above seems like a rather broad overview of OO and the RM. I
> am not sure what you are seeking an opinion about. As a general rule
> online, the more specific the question the better then answers.
>
> The relational model is symbolic logic.
>
> OO is a low-level mechanism for creating large unpredictable state
> machines out of smaller predictable state machines. OO is all about
> managing variables.
>
> After OO was created, folks noted that it has some utility for
> abstraction and reuse. However, the RM is a much better model for
> abstraction, has a more sound foundation, and provides more effective reuse.

0
cimode (135)
6/1/2006 9:48:03 AM
> It is strange to hear talks about identity from RM side. I thought RM
> overcame that disease. There is no identity. Files are same, neither is
> real. Paths aren't same. Identity is a relation, isn't it? Now if you'd
> consider objects like (path,file), these could have identity defined as
> id((path,file))=path.

In the sense that "identity" refers to "the quality of being
identical", there is of course nothing strange in the RM crowd using
that term.

Note that "being identical" requires two things, for else equality
between them cannot be measured/observed/tested.

Note further that the OO crowd always uses the term with respect to one
single thing ("the identity of an object").

The OO crowd thus never uses that term in the "relational" sense of the
word.

0
e.smout (9)
6/1/2006 9:58:43 AM
Marshall wrote:
> Bruno Desthuilliers wrote:
> 
>>frebe73@gmail.com a �crit :
>>
>>I'm afraid your confusing OO (ie: *object* oriented) with
>>"class-oriented" (like in Java). In a "true OO language", *everything*
>>is an object. So functions are objects too. So functions are first-order.
> 
> 
> Java is object oriented by any reasonable definition of the term.

I did not claim to be reasonnable !-)

<troll-warning>
If you firmly believe that OO is about classes, inheritence and
data-hiding, and that Java is the state-of-the-art OOPL, please don't
read further....

> Your claim about "*everything* is an object" and therefore in an
> OOPL, functions must be objects, is not valid. It is not the
> case that *everything* in an OOPL is an object. Is a comment
> an object? 

class MyClass(object):
   """ this comment is a string object,
        and it's an attribute of MyClass
   """

   def myMethod(self, *args, **kw):
     """ this comment is also a string object,
         and it's an attribute of the myMethod object - which
         is itself an attribute of MyClass
     """
     pass


> Is private or public an object?

In most languages, they are statements, so not something that can be
manipulated by the program. But FWIW, one could implement access
restriction in Python with 'function decorators' (HOFs), so that would
make them objects too.

> Is a field an
> object? No.

What's a "field" ? If you mean an attribute, of course it's an object.

> OOPLs have methods. 

Which are nothing more than functions bound to objects.

> There is no requirement to have
> functions be objects to qualify an as OOPL.

There is no requirement to have access restrictors to qualify as an
OOPL. There is no requirement to have inheritence to qualify as an OOPL.
 There is no requirement to even have classes to qualify as an OOPL.
There's one requirement to qualify as an OOPL : to have objects. And
FWIW, that there's no other type. I wouldn't qualify as an OOPL any
language that have non-object types. Java, C++ etc do have primitive
types, so they are not fully object-oriented.

I do understand that 'mixed' (partly OO) languages may be of interest if
one want a low-level language with higher level constructs too, but that
doesn't make them true object languages - just like having functional
constructs in a langage is not enough to make it a functional language.
FWIW, no one in it's own mind would qualify Python or Javascript as
functional languages, while they both support some functional features.

Now 'code' is data too. Really, it is, even at the lower level - or
else, how could one have things like function pointers in C and C++ ? So
to be object all the way, a language must support functions as objects.
CQFD.

</troll-warning>

Ok, you can now proceed to flame me, boys... !-)

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/1/2006 10:17:32 AM
"Erwin" <e.smout@myonline.be> wrote in message
news:1149155923.106878.32800@y43g2000cwc.googlegroups.com...
> > It is strange to hear talks about identity from RM side. I thought RM
> > overcame that disease. There is no identity. Files are same, neither is
> > real. Paths aren't same. Identity is a relation, isn't it? Now if you'd
> > consider objects like (path,file), these could have identity defined as
> > id((path,file))=path.

> In the sense that "identity" refers to "the quality of being
> identical", there is of course nothing strange in the RM crowd using
> that term.

> Note that "being identical" requires two things, for else equality
> between them cannot be measured/observed/tested.

What things ? How is this "identity" distinct from "equality" ?
If it isn't, then why another word ?


0
x
6/1/2006 10:28:11 AM
On 1 Jun 2006 02:58:43 -0700, Erwin wrote:

>> It is strange to hear talks about identity from RM side. I thought RM
>> overcame that disease. There is no identity. Files are same, neither is
>> real. Paths aren't same. Identity is a relation, isn't it? Now if you'd
>> consider objects like (path,file), these could have identity defined as
>> id((path,file))=path.
> 
> In the sense that "identity" refers to "the quality of being
> identical", there is of course nothing strange in the RM crowd using
> that term.
> 
> Note that "being identical" requires two things, for else equality
> between them cannot be measured/observed/tested.
> 
> Note further that the OO crowd always uses the term with respect to one
> single thing ("the identity of an object").

This is not true. As for identity of objects there are many of. For
example, polymorphic objects have the identity of its specific type. The
identity of objects in its usual sense is not required in OO. It is quite
possible to have unidentifiable objects.

> The OO crowd thus never uses that term in the "relational" sense of the
> word.

I don't see much difference in respect of identity. The standpoint is that
there is no data, only behavior. Data is expressed in observed behavior. So
there is no immanent identity of values. There is only "=" relation defined
on them (if any). The object is same as long as it exposes same behavior.
Any question about what is inside is illegal.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/1/2006 10:38:08 AM
> Fair enough.  But in that case you have at least committed to using a
> SQL DBMS, and that it will be from one of the major players in the
> market.  That is somewhat different from RCM's position, which is (as I
> understand it) that it should be trivial to unplug your SQL DBMS and
> replace it by something else that doesn't even use SQL.

The big questing is: Why do you want to unplug the SQL DBMS? It is very
likely that the application programming language will be replace long
before SQL is replaced. In that case, all work to decouple the the
application from the DBMS is wasted. The productivity using an embedded
approach (LAMP for example) is much higher than an layered/decoupled
approach. If you make the decision to take this extra cost you need to
be pretty sure that your application programming language will survive
longer than SQL.

The (possible) future replacement for SQL (and the relational model)
will probably be something that are very hard to imagine at the current
moment. If we design an interface between the database and the
application today, it is not likely that it will fit the next
generation architecture. I have seen old applications using index file
system with an interface between the application and the datastore.
When the index file system is replaced by a SQL database, SQL had to be
used in a very primitive way, because the designers of the interface
could not imagine how future SQL databases would look like.

If we look back at the history we can see that every generation of
databases have been more high-level and has reduced the amount of logic
you have to put in the application. It is resonable to believe that the
next generation of database will do a lot of stuff that the
applications do today.

Fredrik Bertilsson
http://frebe.php0h.com

0
frebe73 (444)
6/1/2006 10:56:01 AM
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:12sh1oeeq72os$.1cm06guz61xq9.dlg@40tude.net...
> On Thu, 01 Jun 2006 01:48:55 GMT, J M Davitt wrote:

> It is strange to hear talks about identity from RM side. I thought RM
> overcame that disease. There is no identity. Files are same, neither is
> real. Paths aren't same. Identity is a relation, isn't it? Now if you'd
> consider objects like (path,file), these could have identity defined as
> id((path,file))=path.

File versioning anyone ?


0
x366 (42)
6/1/2006 10:56:14 AM
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1lrornqlsngid.1g1itr3c2tr04$.dlg@40tude.net...
> On 1 Jun 2006 02:58:43 -0700, Erwin wrote:

> >
> > Note further that the OO crowd always uses the term with respect to one
> > single thing ("the identity of an object").
>
> This is not true. As for identity of objects there are many of. For
> example, polymorphic objects have the identity of its specific type. The
> identity of objects in its usual sense is not required in OO. It is quite
> possible to have unidentifiable objects.

UFOs ?

> > The OO crowd thus never uses that term in the "relational" sense of the
> > word.

> I don't see much difference in respect of identity. The standpoint is that
> there is no data, only behavior.

> Data is expressed in observed behavior.

What this means ? How ?
The change of data is the data but there is no data ?




0
x366 (42)
6/1/2006 11:01:18 AM
On Thu, 1 Jun 2006 13:56:14 +0300, x wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:12sh1oeeq72os$.1cm06guz61xq9.dlg@40tude.net...
>> On Thu, 01 Jun 2006 01:48:55 GMT, J M Davitt wrote:
> 
>> It is strange to hear talks about identity from RM side. I thought RM
>> overcame that disease. There is no identity. Files are same, neither is
>> real. Paths aren't same. Identity is a relation, isn't it? Now if you'd
>> consider objects like (path,file), these could have identity defined as
>> id((path,file))=path.
> 
> File versioning anyone ?

My last one was RSX-11M (alas, I must say). The file version number was a
part of the path there: DK1:[1,54]FILE.FTN;25, if I correctly remember...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/1/2006 11:07:48 AM
On Thu, 1 Jun 2006 14:01:18 +0300, x wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:1lrornqlsngid.1g1itr3c2tr04$.dlg@40tude.net...
>> On 1 Jun 2006 02:58:43 -0700, Erwin wrote:
> 
>>>
>>> Note further that the OO crowd always uses the term with respect to one
>>> single thing ("the identity of an object").
>>
>> This is not true. As for identity of objects there are many of. For
>> example, polymorphic objects have the identity of its specific type. The
>> identity of objects in its usual sense is not required in OO. It is quite
>> possible to have unidentifiable objects.
> 
> UFOs ?

Yes, if the fly! (:-))

>>> The OO crowd thus never uses that term in the "relational" sense of the
>>> word.
> 
>> I don't see much difference in respect of identity. The standpoint is that
>> there is no data, only behavior.
> 
>> Data is expressed in observed behavior.
> 
> What this means ? How ?
> The change of data is the data but there is no data ?

How do you change data, what is the effect of a change? Both are specified
in operations. Let you have changed the data, but the effect of all
operations you could apply to, is same as before. How can you determine if
you really did? What if I reverted your change while you looked aside. Can
you catch me?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/1/2006 11:21:00 AM
In article <1149159361.846295.4330@g10g2000cwb.googlegroups.com>,
 <frebe73@gmail.com> wrote:
>> Fair enough.  But in that case you have at least committed to using a
>> SQL DBMS, and that it will be from one of the major players in the
>> market.  That is somewhat different from RCM's position, which is (as I
>> understand it) that it should be trivial to unplug your SQL DBMS and
>> replace it by something else that doesn't even use SQL.
>
>The big questing is: Why do you want to unplug the SQL DBMS? 

For a trivial example, consider an application that needs to somehow 
authenticate users (because different users have permission or not for 
different parts of the functonality of the application. The user 
information (name, password, etc) will have to be stored somewhere - a 
relational database might be an excellent place, in particular if this 
application is essentially a stand-alone one.

However, it might be that the application is intented to be integrated 
into an existing infrastructure, that has user information stored in an 
LDAP-accessible database; or for another example, the user information 
might be stored in a Unix-style flat file (a la /etc/passwd).

By separating out the logic that handles any interaction between the 
chosen database into separate, database-specific modules that share a 
common interface, the rest of the application can remain identically the 
same, with only the database-specific parts needing to be plugged in or 
out, depending on the precise environment where the application is 
deployed.

Best wishes,

// Christian Brunschen

0
cb5180 (38)
6/1/2006 11:25:29 AM
frebe73@gmail.com wrote:
> > Fair enough.  But in that case you have at least committed to using a
> > SQL DBMS, and that it will be from one of the major players in the
> > market.  That is somewhat different from RCM's position, which is (as I
> > understand it) that it should be trivial to unplug your SQL DBMS and
> > replace it by something else that doesn't even use SQL.
>
> The big questing is: Why do you want to unplug the SQL DBMS? It is very
> likely that the application programming language will be replace long
> before SQL is replaced. In that case, all work to decouple the the
> application from the DBMS is wasted. The productivity using an embedded
> approach (LAMP for example) is much higher than an layered/decoupled
> approach. If you make the decision to take this extra cost you need to
> be pretty sure that your application programming language will survive
> longer than SQL.

In my world there are two distinct types of application programming:
user interface application programming, and database application
programming.  It makes sense to embed SQL in the database code for the
reasons you give, but not in the UI code.  The UI is the most likely
bit to change in the near future, as we respond to the prevailing
tastes of the user community ("we want it
GUI-based/browser-based/mobile-based/...")  The database part OTOH may
not need to change for a long time, provided it performs well and
serves the UI well.  The interface between the UI and the database is
at the level  of business functions (e.g. "create an order", "produce
bills for this month", etc.) and is typically an API.

One could argue that to the UI programmer, the database is a "bit
bucket" (very ugly term) of which he/she needs to know little.
However, the UI is probably only 10-20% of the code, with 80-90% being
the database application code - and to write this well you need to know
your DBMS.

This is a lot different from RCM's stance (as I understand it), which
is that even the developer writing the database code - the "guts" of
the data processing - shouldn't need to know anything about the DBMS.
I don't agree with this.

0
andrewst1 (87)
6/1/2006 11:58:07 AM
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:sxtsljxfome3$.nxcpez0f5mdg.dlg@40tude.net...
> On Thu, 1 Jun 2006 14:01:18 +0300, x wrote:
>
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> > news:1lrornqlsngid.1g1itr3c2tr04$.dlg@40tude.net...
> >> On 1 Jun 2006 02:58:43 -0700, Erwin wrote:

> >> I don't see much difference in respect of identity. The standpoint is
that
> >> there is no data, only behavior.
> >
> >> Data is expressed in observed behavior.
> >
> > What this means ? How ?
> > The change of data is the data but there is no data ?

> How do you change data, what is the effect of a change?

No. How can I observe the behavior if there is no data.

> Both are specified
> in operations. Let you have changed the data, but the effect of all
> operations you could apply to, is same as before. How can you determine if
> you really did? What if I reverted your change while you looked aside. Can
> you catch me?

I think I'll not catch you 'cause I didn't played this game before.


0
x366 (42)
6/1/2006 12:18:37 PM
> For a trivial example, consider an application that needs to somehow
> authenticate users (because different users have permission or not for
> different parts of the functonality of the application. The user
> information (name, password, etc) will have to be stored somewhere - a
> relational database might be an excellent place, in particular if this
> application is essentially a stand-alone one.
>
> However, it might be that the application is intented to be integrated
> into an existing infrastructure, that has user information stored in an
> LDAP-accessible database; or for another example, the user information
> might be stored in a Unix-style flat file (a la /etc/passwd).

Yes, authentication data may be stored in older obsolete hierachial
databases (LDAP). Using a pluggable solution is a good strategy here,
like JAAS if you are using Java. But I have never seen any
authentication solution were you actually get username and password
from the store. Instead you ask a serverice if your username/password
pair is correct or not. In this case, the interface sould not be
between the application and the database, but between the application
and a pluggable service.

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.

Actually it would also be possible to write an own ODBC driver catching
the SQL statements accesing the "user" table and call the LDAP database
instead. (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.)

Fredrik Bertilsson
http://frebe.php0h.com

0
frebe73 (444)
6/1/2006 12:40:01 PM
> It makes sense to embed SQL in the database code for the
> reasons you give, but not in the UI code.  The UI is the most likely
> bit to change in the near future, as we respond to the prevailing
> tastes of the user community ("we want it
> GUI-based/browser-based/mobile-based/...")  The database part OTOH may
> not need to change for a long time, provided it performs well and
> serves the UI well.

So, what is the gain in separating the SQL statements if the they can
be regarded as constants?

> The interface between the UI and the database is
> at the level  of business functions (e.g. "create an order", "produce
> bills for this month", etc.) and is typically an API.

The interface database between the UI and the database could be SQL
statements (just look at sucessful LAMP applications out there), but it
could also of course be functions/methods too. Every time you have a
fragments of code that is likely to be called from multiple points in
the application, you should do a function/method. But what is the point
in a method like this:

function createOrder(id, customerid, deleiverydate)
{
    insert into order values (id, customerid, deliverydate);
}

Fredrik Bertilsson
http://frebe.php0h.com

0
frebe73 (444)
6/1/2006 12:47:40 PM
"Christian Brunschen" <cb@festis.df.lth.se> wrote in message
news:e5mir9$gug$1@news.lth.se...
> In article <1149159361.846295.4330@g10g2000cwb.googlegroups.com>,
>  <frebe73@gmail.com> wrote:
> >> Fair enough.  But in that case you have at least committed to using a
> >> SQL DBMS, and that it will be from one of the major players in the
> >> market.  That is somewhat different from RCM's position, which is (as I
> >> understand it) that it should be trivial to unplug your SQL DBMS and
> >> replace it by something else that doesn't even use SQL.
> >
> >The big questing is: Why do you want to unplug the SQL DBMS?
>
> For a trivial example, consider an application that needs to somehow
> authenticate users (because different users have permission or not for
> different parts of the functonality of the application. The user
> information (name, password, etc) will have to be stored somewhere - a
> relational database might be an excellent place, in particular if this
> application is essentially a stand-alone one.

What makes the example trivial?  Do you mean trivial in the sense that
mathematicians use the word, in the sense that engineers use the word,  or
in the sense that common parlance uses the word?


0
dcressey (35)
6/1/2006 12:54:41 PM
frebe73@gmail.com wrote:
>>It makes sense to embed SQL in the database code for the
>>reasons you give, but not in the UI code.  The UI is the most likely
>>bit to change in the near future, as we respond to the prevailing
>>tastes of the user community ("we want it
>>GUI-based/browser-based/mobile-based/...")  The database part OTOH may
>>not need to change for a long time, provided it performs well and
>>serves the UI well.
> 
> So, what is the gain in separating the SQL statements if the they can
> be regarded as constants?

If one accepts Tony's premise, the gain is in not losing the SQL 
statements (assuming one uses SQL) when one deletes the obsolete UI code 
a couple years down the road.

If one accepts your premise, there is no gain in separating any code 
since one can regard it all as constant.
0
bbadour (434)
6/1/2006 1:22:15 PM
In article <lsBfg.3076$%86.209@trndny04>,
David Cressey <dcressey@verizon.net> wrote:
>
>"Christian Brunschen" <cb@festis.df.lth.se> wrote in message
>news:e5mir9$gug$1@news.lth.se...
>> For a trivial example, consider an application that needs to somehow
>> authenticate users [ ... ]
>
>What makes the example trivial?  Do you mean trivial in the sense that
>mathematicians use the word, in the sense that engineers use the word,  or
>in the sense that common parlance uses the word?

In a very loose common parlance sense of the example being easy to come up 
with, not being contrived and thus something that people do occasionally 
encounter.

Best wishes,

// Christian Brunschen
0
cb5180 (38)
6/1/2006 1:50:18 PM
On Thu, 1 Jun 2006 15:18:37 +0300, x wrote:

> No. How can I observe the behavior if there is no data.

Where is a problem with that? What data do you need to observe behavior of,
say, a real-valued function?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/1/2006 2:21:39 PM
Dmitry A. Kazakov wrote:
> On Thu, 01 Jun 2006 02:09:29 GMT, J M Davitt wrote:
>
> Concerning constraints, you wouldn't need any, in a purely declarative
> language. Constraint limits space where an imperative action can be taken.

This is not correct. Declarative isn't the alternative to imperative;
functional is. Anyway, declarative constraints are useful
in any language, even a purely functional one.


> I'd like to see some proof. In my personal, limited, ignorant, etc
> experience domain-oriented languages are in order of magnitude worse than
> worst OOPLs (like C++, for example). Practically all our customers start
> with some sort of domain-oriented language, be it SQL, Simulink etc. Yes,
> they get first 20% of functional requirements very quickly. Then, they
> discover that the rest cannot be made at any cost, that maintenance is a
> disaster, that non-functional requirements is what they should forever
> forget of. Our job is basically to throw all that domain-oriented rubbish
> away. Gradually, slowly, so that the customer wouldn't see it. In five
> years or so he gets a working system with 5% or less legacy code.

This story doesn't make any sense to me. DSLs are not intended
as a general purpose solution; that's what the "S" stands for.
And a DSL will of course be a *better* way of working with its
domain than a general purpose language. Replacing a general
purpose tool for a special pupose one within the special purpose
one's domain is not good for anyone, unless the goal is to
maximize billable hours.


Marshal

0
6/1/2006 2:22:14 PM
In article <1149165601.331313.237840@u72g2000cwu.googlegroups.com>,
 <frebe73@gmail.com> wrote:
>> For a trivial example, consider an application that needs to somehow
>> authenticate users (because different users have permission or not for
>> different parts of the functonality of the application. The user
>> information (name, password, etc) will have to be stored somewhere - a
>> relational database might be an excellent place, in particular if this
>> application is essentially a stand-alone one.
>>
>> However, it might be that the application is intented to be integrated
>> into an existing infrastructure, that has user information stored in an
>> LDAP-accessible database; or for another example, the user information
>> might be stored in a Unix-style flat file (a la /etc/passwd).
>
>Yes, authentication data may be stored in older obsolete hierachial
>databases (LDAP). 

LDAP is not usually considered 'obsolete'. For its specific purpose it 
appears to be fairly well-liked and in widespread use.

>Using a pluggable solution is a good strategy here,
>like JAAS if you are using Java. But I have never seen any
>authentication solution were you actually get username and password
>from the store. Instead you ask a serverice if your username/password
>pair is correct or not. In this case, the interface sould not be
>between the application and the database, but between the application
>and a pluggable service.

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. 
Either way, we expose an interface of our own choosing to the application, 
which is thus insulated from the details of how we have implemented user 
authentication, including the type of user information database that we 
may or may not have available.

Consider also the case where there is additional per-user information that 
is in fact stored in the database (such as the location of the user's home 
sirectory), which we wish to retrieve and somehow use in the application. 
In my opinion, a good way to proceed would be to create an interface that 
exposes an operation to 'retrieve a given user's home directory', and to 
then implement that in a way that best uses the interface offered by the 
specific database we are using (whether by choice or by force).

>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. The 
name of each function/procedure/method should reveal its intent, and its 
body should contain the implementation. The precise language or languages 
that the procedure is written in is fairly immaterial. I would much rather 
have a procedure to call named 'getUserHomeDirectory(...)' (or a method, 
'[user homeDirectory]' as an example in Objective-C syntax), than having 
to explicitly invoke whatever underlying code might be necessary; among 
other things, this then lets me change the body of the procedure as 
necessary, while keeping its interface the same. That way, I can, when I 
go to write application code that actually needs to authenticate a user, 
just use the appropriately named procedure/method/function, which leave my 
application code nice and readable while stating the intent of what is 
going on but hiding the details.

This doesn't just insulate us from having to replace SQL with something 
else (which might well be extremely unlikely witin the lifespan of the 
application and its data model), but it also insulates us from changes to 
the implementation details, such as, say, if someone imposed a different 
naming convention on tables and columns (such things have been known to 
happen), or the structure of the database needs to change for some other 
reason. (Yes, some of these things can probably be addressed using SQL 
Views, but the fact that a specific workaround exists doesn't invalidate 
the general technique.)

>Actually it would also be possible to write an own ODBC driver catching
>the SQL statements accesing the "user" table and call the LDAP database
>instead. 

.... 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. 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. The main difference 
is that you appear to prefer putting a more generic interface in place, 
whereas I prefer a more specific one. There are good arguments on both 
sides.

> (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.

>Fredrik Bertilsson

Best wishes,

>http://frebe.php0h.com

// Christian Brunschen
0
cb5180 (38)
6/1/2006 2:25:54 PM
Christian Brunschen wrote:
>
> For a trivial example, consider an application that needs to somehow
> authenticate users (because different users have permission or not for
> different parts of the functonality of the application. The user
> information (name, password, etc) will have to be stored somewhere - a
> relational database might be an excellent place, in particular if this
> application is essentially a stand-alone one.
>
> However, it might be that the application is intented to be integrated
> into an existing infrastructure, that has user information stored in an
> LDAP-accessible database; or for another example, the user information
> might be stored in a Unix-style flat file (a la /etc/passwd).
>
> By separating out the logic that handles any interaction between the
> chosen database into separate, database-specific modules that share a
> common interface, the rest of the application can remain identically the
> same, with only the database-specific parts needing to be plugged in or
> out, depending on the precise environment where the application is
> deployed.

There's a severe problem with that logic, though.

If you want to build a layer to wrap a variety of different storage
mechanisms, that layer *cannot* be any more powerful than
the weakest mechanism you want to layer on top of. Which
means your very high level, very powerful SQL dbms will
be stuck at the level of the stupidest file store ever invented.

And in swoops the application programmer to "save" the day
from the problem he invented! All he has to do is write that
subset of a DBMS that he needs today. Which will slowly,
over time, increase until it's a badly implemented, bug ridden,
ad hoc implementation of half of a database. This is
Spight's Law. You have to have a dbms, whether you
use a good one or reinvent it yourself, badly.

To put it in the terms of application programming, it is as if
we decided we want to be able to swap our programming
language one for another at will. So we can't use any features
of any programming language that isn't in all of them.
Oh, and we want assembly to be on the list.


Marshall

PS. Props to Greenspun's Tenth.

0
6/1/2006 2:32:15 PM
Cimode wrote:

> Thanks for the guidance...I will keep in mind your advice to give more
> targetted questions...The subject would be to find out how and what OO
> mechanisms (nice definition) can contribute to build better
> implementations of relational requirements throughout the system life
> cycle...
> 
> Questions I would like to discuss are of the following type:
> 
>>What are the available OO languages that can do a better job than SQL into handling data definition and manipulation...Java?
>>What are the limitations of these languages to do what's above? What's currently missing in OO (Is object "persistence" a desperate attempt at establishing representations of R Tables)
> 
> My point is to help establish a practical list of feature (some kind of
> Bill of Material) of important requirements OO languages should meet to
> be potential candidates to better allow relational implementation.  I
> do believe this kind of debate can be more useful that raw opposition
> between programmers and relational advocates.  As you stated, OO can in
> no case be put on the same standpoint than relational model as they are
> of  totally different nature...In a schematic manner, it seems OO is
> more about implementation than abstraction only a model can bring.  It
> also seems to me OO mechanisms could do as well as current SQL (at
> least its current form) into implementing better DBMS... Question is
> how?

You underestimate the power of a good formalism. OO doesn't stand a 
chance even against SQL.
0
bbadour (434)
6/1/2006 2:38:30 PM
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1qh0bg01l3rh1$.b18js04t02uv.dlg@40tude.net...
> On Thu, 1 Jun 2006 15:18:37 +0300, x wrote:
>
> > No. How can I observe the behavior if there is no data.

> Where is a problem with that? What data do you need to observe behavior
of,
> say, a real-valued function?

I do not know what you call behavior.
To answer the question: I need the function.


0
x366 (42)
6/1/2006 2:40:58 PM
Tony Andrews wrote:
> frebe73@gmail.com wrote:
> 
>>>Fair enough.  But in that case you have at least committed to using a
>>>SQL DBMS, and that it will be from one of the major players in the
>>>market.  That is somewhat different from RCM's position, which is (as I
>>>understand it) that it should be trivial to unplug your SQL DBMS and
>>>replace it by something else that doesn't even use SQL.
>>
>>The big questing is: Why do you want to unplug the SQL DBMS? It is very
>>likely that the application programming language will be replace long
>>before SQL is replaced. In that case, all work to decouple the the
>>application from the DBMS is wasted. The productivity using an embedded
>>approach (LAMP for example) is much higher than an layered/decoupled
>>approach. If you make the decision to take this extra cost you need to
>>be pretty sure that your application programming language will survive
>>longer than SQL.
> 
> 
> In my world there are two distinct types of application programming:
> user interface application programming, and database application
> programming.  It makes sense to embed SQL in the database code for the
> reasons you give, but not in the UI code.  The UI is the most likely
> bit to change in the near future, as we respond to the prevailing
> tastes of the user community ("we want it
> GUI-based/browser-based/mobile-based/...")  The database part OTOH may
> not need to change for a long time, provided it performs well and
> serves the UI well.  The interface between the UI and the database is
> at the level  of business functions (e.g. "create an order", "produce
> bills for this month", etc.) and is typically an API.
> 
> One could argue that to the UI programmer, the database is a "bit
> bucket" (very ugly term) of which he/she needs to know little.
> However, the UI is probably only 10-20% of the code, with 80-90% being
> the database application code - and to write this well you need to know
> your DBMS.

Actually, you have that backward. In my experience, the combination of 
exception-handling and user-interface code account for well over 90% of 
the code in a typical 3gl/4gl application.
0
bbadour (434)
6/1/2006 2:43:44 PM
On 1 Jun 2006 07:22:14 -0700, Marshall wrote:

> Dmitry A. Kazakov wrote:
>> On Thu, 01 Jun 2006 02:09:29 GMT, J M Davitt wrote:
>>
>> Concerning constraints, you wouldn't need any, in a purely declarative
>> language. Constraint limits space where an imperative action can be taken.
> 
> This is not correct.

Why?

> Declarative isn't the alternative to imperative;
> functional is.

Yes

> Anyway, declarative constraints are useful
> in any language, even a purely functional one.

Sure. No less they are useful in an OO language. Specialization by
constraining is a very powerful mechanism.

>> I'd like to see some proof. In my personal, limited, ignorant, etc
>> experience domain-oriented languages are in order of magnitude worse than
>> worst OOPLs (like C++, for example). Practically all our customers start
>> with some sort of domain-oriented language, be it SQL, Simulink etc. Yes,
>> they get first 20% of functional requirements very quickly. Then, they
>> discover that the rest cannot be made at any cost, that maintenance is a
>> disaster, that non-functional requirements is what they should forever
>> forget of. Our job is basically to throw all that domain-oriented rubbish
>> away. Gradually, slowly, so that the customer wouldn't see it. In five
>> years or so he gets a working system with 5% or less legacy code.
> 
> This story doesn't make any sense to me. DSLs are not intended
> as a general purpose solution; that's what the "S" stands for.
> And a DSL will of course be a *better* way of working with its
> domain than a general purpose language.

The only problem is to find the domain... I have an impression that the
sole domain of many DSLs is actually money-making.

> Replacing a general
> purpose tool for a special pupose one within the special purpose
> one's domain is not good for anyone, unless the goal is to
> maximize billable hours.

It is better to be able to find the tool in the same tool box.

I prefer to have special purpose solutions in the form of libraries of an
universal-purpose language.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/1/2006 2:53:43 PM
On Thu, 1 Jun 2006 17:40:58 +0300, x wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:1qh0bg01l3rh1$.b18js04t02uv.dlg@40tude.net...
>> On Thu, 1 Jun 2006 15:18:37 +0300, x wrote:
>>
>>> No. How can I observe the behavior if there is no data.
> 
>> Where is a problem with that? What data do you need to observe behavior of,
>> say, a real-valued function?
> 
> I do not know what you call behavior.

Yet you know what you call data?

> To answer the question: I need the function.

exp()

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/1/2006 3:01:43 PM
<<You underestimate the power of a good formalism.>>
I am not sure what you intend by *good formalism*...If by *formalism*
you mean *coherence* then I totally agree...(Thanks for clarifying this
for I may have misunderstood)

Because of its coherence, I realized that the thinking mechanism and
semantics that allows to build SQL statements probably meets logic of
extraction requirements better than any other language.   My impression
however is that it does not sufficiently drive better in memory
implementation R Tables and even goes counterstream to a real
independence between the logical and physical layer.  In a word, I am
under the impression that SQL (which was not initially thought of as it
is now) is becoming a limitation of the relational model.  Which is why
a question may be asked which is: can OO bring something to that?  I
kept hearing about OO fuss about so many years that I am interested now
as what it may concretely bring to relational implementation... For
instance inheritance is something that may prove extremely useful in
the implementation of subtype/supertype RTables.

What is your thought about that?  Thank you for your feedback..

Bob Badour wrote:
> Cimode wrote:
>
> > Thanks for the guidance...I will keep in mind your advice to give more
> > targetted questions...The subject would be to find out how and what OO
> > mechanisms (nice definition) can contribute to build better
> > implementations of relational requirements throughout the system life
> > cycle...
> >
> > Questions I would like to discuss are of the following type:
> >
> >>What are the available OO languages that can do a better job than SQL into handling data definition and manipulation...Java?
> >>What are the limitations of these languages to do what's above? What's currently missing in OO (Is object "persistence" a desperate attempt at establishing representations of R Tables)
> >
> > My point is to help establish a practical list of feature (some kind of
> > Bill of Material) of important requirements OO languages should meet to
> > be potential candidates to better allow relational implementation.  I
> > do believe this kind of debate can be more useful that raw opposition
> > between programmers and relational advocates.  As you stated, OO can in
> > no case be put on the same standpoint than relational model as they are
> > of  totally different nature...In a schematic manner, it seems OO is
> > more about implementation than abstraction only a model can bring.  It
> > also seems to me OO mechanisms could do as well as current SQL (at
> > least its current form) into implementing better DBMS... Question is
> > how?
>
> You underestimate the power of a good formalism. OO doesn't stand a
> chance even against SQL.

0
cimode (135)
6/1/2006 3:22:08 PM
In article <1149172334.971049.210600@u72g2000cwu.googlegroups.com>,
Marshall <marshall.spight@gmail.com> wrote:
>Christian Brunschen wrote:
>>
>> For a trivial example, consider an application that needs to somehow
>> authenticate users (because different users have permission or not for
>> different parts of the functonality of the application. The user
>> information (name, password, etc) will have to be stored somewhere - a
>> relational database might be an excellent place, in particular if this
>> application is essentially a stand-alone one.
>>
>> However, it might be that the application is intented to be integrated
>> into an existing infrastructure, that has user information stored in an
>> LDAP-accessible database; or for another example, the user information
>> might be stored in a Unix-style flat file (a la /etc/passwd).
>>
>> By separating out the logic that handles any interaction between the
>> chosen database into separate, database-specific modules that share a
>> common interface, the rest of the application can remain identically the
>> same, with only the database-specific parts needing to be plugged in or
>> out, depending on the precise environment where the application is
>> deployed.
>
>There's a severe problem with that logic, though.
>
>If you want to build a layer to wrap a variety of different storage
>mechanisms, that layer *cannot* be any more powerful than
>the weakest mechanism you want to layer on top of. Which
>means your very high level, very powerful SQL dbms will
>be stuck at the level of the stupidest file store ever invented.

That's not true.

*If* all the wrapper did was translate APIs, *then* it might be true. 
However, the wrapper can itself choose to delegate functionality, or 
implement it itself if necessary.

>And in swoops the application programmer to "save" the day
>from the problem he invented! All he has to do is write that
>subset of a DBMS that he needs today. Which will slowly,
>over time, increase until it's a badly implemented, bug ridden,
>ad hoc implementation of half of a database. This is
>Spight's Law. You have to have a dbms, whether you
>use a good one or reinvent it yourself, badly.

This argument can actually be generalized to any service: If you want to 
use a service, and you don't have that service available, you have to 
implement it yourself - or at least those parts of it that you need. f you 
only need a small subset, that may not be a problem; if you need all of 
it, you may end up having to write the whole thing. This isn't in any way 
special for databases. If you need to have multiple concurrent 
communication channels open to adifferent device over a single underlying 
channel, you can either use existing, concurrent-channel-capable services 
(such as using PPP over the serial link to connect to the device, and 
simply opening multiple TCP/IP connections to it), or you will have to 
write a service - in this case a communications protocol - that manages to 
multiplex your severl channels over the single underlying one. Yet 
precisely that solution may in fact be the better one for the specific 
problem, for instance if the other device is an embedded one and has no 
room for a PPP and TCP/IP stack, but since your problem only needs part of 
what TCP/IP-over-PPP offers, implementing your own small, specific 
protocol is a solution that works, and is entirely appropriate.

So basically: for any service you use, you need to either get an existing 
implementation that offers you everything you need, or write at least 
parts of it yourself.

In *many* cases, using an existing, pre-built relational database - or 
a pre-built implementation of whatever service it is you need - will be 
exactly the right thing to do. But in some other cases, where the full 
strength of the relational model is not needed, and indeed other concerns 
may be more important (performance for instance), the appropriate solution 
may be to use a less powerful underlying mechanism, and implement on top 
of it precisely those parts of a database management system that you need. 
(In which case one should, of course, read up on how best to implement 
those features, and implement them well.)

To reconnect this to the authentication example, there may be an existing 
system in place for some of the application's deployments which offers 
user authentication out of the box; in that case, the wrapper will be a 
very thin one. In other deployments, no such service might exist, but 
there might be an RDBMS available. In this case, the RDBMS may offer less 
functionality than the pre-built user-authentication service we had 
available in the first deployment; however, using the RDBMS to store the 
usernames and encrypted passwords, and using suitable select statements, 
we can implement a user authentication service using the RDBMS as one 
component, and implementing any missing functionality within the wrapper.

>To put it in the terms of application programming, it is as if
>we decided we want to be able to swap our programming
>language one for another at will. So we can't use any features
>of any programming language that isn't in all of them.
>Oh, and we want assembly to be on the list.

Again, please see the discussion above. That there might be a lack of 
certain features in some of the available services does not preclude more 
powerful services being built on top of them, as long as it there is a 
sufficiently powerful extension facility available.

The example of assembly language is rather cute; but then, from assembly 
language it is quite possible to call into functions written in C, or any 
other language, or into a Smalltalk runtime system, etc ... So in a system 
where one wants to be able to use assembly language, there's actually no 
reason to not write parts of that system in some other arbitrary language, 
and indeed using arbitrary features from those languages (as long as there 
is a working interface between the two).

>Marshall

Best wishes,

// Christian Brunschen

>PS. Props to Greenspun's Tenth.

?
0
cb5180 (38)
6/1/2006 3:26:57 PM
Dmitry A. Kazakov wrote:
> On Thu, 01 Jun 2006 02:50:54 +0200, Bruno Desthuilliers wrote:
>
> > I'm afraid your confusing OO (ie: *object* oriented) with
> > "class-oriented" (like in Java). In a "true OO language", *everything*
> > is an object. So functions are objects too. So functions are first-order.
>
> I don't think it could be consistent to have everything an object. Though
> it is possible to have object corresponding to functions.

Function is a set of ordered pairs such that a certain condition is
met. Where is "object" in this definition?

0
6/1/2006 4:08:23 PM
Cimode wrote:
> In a word, I am
> under the impression that SQL (which was not initially thought of as it
> is now) is becoming a limitation of the relational model.

This is urban myth. SQL is widely criticised for its NULL and duplicate
treatment. There is several more little annoying inconsistencies.
That's about it. On practice, I fire SQL query and rarely get a
surprising result that can be attributed to SQL deficiency.

This is what makes SQL hard to replace by a superior language. Keep in
mind that some widely sucessful SQL features like "group-by" are
ad-hock and are not part of the relational model.

> Which is why
> a question may be asked which is: can OO bring something to that?   I
> kept hearing about OO fuss about so many years that I am interested now
> as what it may concretely bring to relational implementation... For
> instance inheritance is something that may prove extremely useful in
> the implementation of subtype/supertype RTables.

I doubt naive OO method would contribute anything. If you want in-depth
theory of inheritance, classification then check up formal concept
analysis (Uta Priss has written a nice survey article). Formal concept
analysis provides a nice set-theoretic model for many OO artifacts such
as multiple inheritance, for instance.

0
6/1/2006 4:45:29 PM
On 1 Jun 2006 09:08:23 -0700, Mikito Harakiri wrote:

> Dmitry A. Kazakov wrote:
>> On Thu, 01 Jun 2006 02:50:54 +0200, Bruno Desthuilliers wrote:
>>
>>> I'm afraid your confusing OO (ie: *object* oriented) with
>>> "class-oriented" (like in Java). In a "true OO language", *everything*
>>> is an object. So functions are objects too. So functions are first-order.
>>
>> I don't think it could be consistent to have everything an object. Though
>> it is possible to have object corresponding to functions.
> 
> Function is a set of ordered pairs such that a certain condition is
> met. Where is "object" in this definition?

I said - an object corresponding to function. Function is the value of that
object. If 2 can be a value, why a function cannot be? But that is rather
trivial and uninteresting. The question was actually about subprograms
rather than mathematical functions. They can be objects. As well as tasks
and paritions when we are talking about concurrency.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/1/2006 5:05:07 PM
Dmitry A. Kazakov wrote:
> On 1 Jun 2006 09:08:23 -0700, Mikito Harakiri wrote:
> > Function is a set of ordered pairs such that a certain condition is
> > met. Where is "object" in this definition?
>
> I said - an object corresponding to function. Function is the value of that
> object. If 2 can be a value, why a function cannot be?

Well, it is easy to understand what the domain of numbers is and what
operations are among them. So I can implement the Integer class. Can
you write a definition of Function class?

> But that is rather trivial and uninteresting.

Well, it's hardly trivial for numbers, why it suddenly becomes trivial
for functions?

> The question was actually about subprograms
> rather than mathematical functions. They can be objects.

So can you write a code that supports your otherwise meaningless
gibberish?

0
6/1/2006 5:19:45 PM
"Tony Andrews" <andrewst@onetel.com> wrote in message
news:1149163087.832586.36310@u72g2000cwu.googlegroups.com...
> frebe73@gmail.com wrote:

> One could argue that to the UI programmer, the database is a "bit
> bucket" (very ugly term) of which he/she needs to know little.
> However, the UI is probably only 10-20% of the code, with 80-90% being
> the database application code - and to write this well you need to know
> your DBMS.

The problem with the above is this:

The UI programmer thinks he/she is on the outside of a capsule that he/she
is really on the inside of.

The problem with the concept of encapsulation is that outside and inside are
not symmetric, but there is no objective method of determining which is
which.



>
> This is a lot different from RCM's stance (as I understand it), which
> is that even the developer writing the database code - the "guts" of
> the data processing - shouldn't need to know anything about the DBMS.
> I don't agree with this.
>

The DBMS has "public parts",  which an app programmer should know,  and
"private parts' which an app programmer, in general, has no need to know,
and may have a need not to know.


0
dcressey (35)
6/1/2006 6:35:58 PM
On 1 Jun 2006 10:19:45 -0700, Mikito Harakiri wrote:

> Dmitry A. Kazakov wrote:
>> On 1 Jun 2006 09:08:23 -0700, Mikito Harakiri wrote:
>>> Function is a set of ordered pairs such that a certain condition is
>>> met. Where is "object" in this definition?
>>
>> I said - an object corresponding to function. Function is the value of that
>> object. If 2 can be a value, why a function cannot be?
> 
> Well, it is easy to understand what the domain of numbers is and what
> operations are among them. So I can implement the Integer class. Can
> you write a definition of Function class?

These are three questions in one. There is a sufficient difference between:

1. Predefined types [of functions]
2. User-defined types of
3. User-defined classes of

To have objects you need only 1. When a function is declared the compiler
can easily create an anonymous type for it. That would be 1. If you want a
type of functions 2. that shouldn't be a big problem either. There is
little difference between that and pointers to functions. You can find them
in practically any language.

Class of functions is more interesting, but if the signature is fixed it
imposes no problem. As a guess, a polymorphic functional objects should
multiple dispatch on the tuple: (function, argument lists, result lists).

Class of all functions, that might be really difficult, if possible. There
are as well many interesting questions about classes of polymorphic
functions, inheritance from functions, relationships between functions on
related types. For example is the type of functions on a subtype a subtype
of the type of functions on the base type? Without an elaborated and
consistent type theory they are difficult to answer.

Operations on functions (subprograms):

1. Mapping (call to) the tuple of arguments to the tuple of results

   Map : f x x1 x  x2 x ... x xN -> y1 x y2 x ... x yN

2. Composition:

   o : f1 x f2 -> f1 (f2 (x))

3. Comparison

   = : f1 x f2 -> Boolean

4. Copy (for marshaling, closures etc)

   := : f -> f

5. Convolution

   * : f1 x f2 x sum x prod x inv -> sum (prod (f(x), g(inv (x)))
 
6. Extension

and so on

>> But that is rather trivial and uninteresting.
> 
> Well, it's hardly trivial for numbers, why it suddenly becomes trivial
> for functions?

Because in this particular case function is a value and values are outside
the language scope. Somewhere in the application domain exists 2. So there
does sine. You don't care what they are. You only need some object to
represent them. Let the bit pattern 0x1 represent 2 and 0x2 do sine. End of
story.

>> The question was actually about subprograms
>> rather than mathematical functions. They can be objects.
> 
> So can you write a code that supports your otherwise meaningless
> gibberish?

Don't you see any difference between mathematical constructs and
programming language objects?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/1/2006 6:38:42 PM
Marshall wrote:
> CMCC wrote:
>
> [scanning back through the thread ...]
>
> Okay, maybe you are asking about this:
>
> >No, a DBMS is a bucket of bits with some low level rules to manage
> >those bits.  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.
> >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.  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.
>
>
> The reason why you see crap like this is because it is being
> written by application developers.

As an application developer I don't recognize myself in it.

 Application developers are
> great at writing applications,

Not all of them. The ones who recognize themselfs in the above
and like to work with *data storages* can not be.

 but once they have success in
> that one area, they overgeneralize and begin to believe that
> their techniques are the correct techniques to apply to every
> software development area. However this represents a
> multi-decade regression in the field of data management.
>
> Data management in the 1960s lacked any understanding
> of the issues that the field has today. And if the application
> programmers have their way, and the existing field of
> data management is discarded, those same application
> programmers will face all the same problems that the
> programmers of the 1960s did, over again. And over
> the decades, they'll build systems that tackle questions
> like integrity enforcement, ad hoc queries, transaction
> management, etc. Slowly, they will reinvent the field.

I agree with this, being also aware of the historical perspective.

>
> And, if they do so, it would be poetic justice if the
> programmers being born today trash all their work
> in favor of some new fad.

I try to hope the next generation wil get it right, but
i think a new fads will replace the ones we have now.

I'm waiting for Dynamic Hyperoriented XML (or.. is it alrady here?)

(I was not ignoring you... i think we simply agree)
Regards,
Carlos

0
c_jackal (9)
6/1/2006 6:41:52 PM
Bob Badour wrote:
> Tony Andrews wrote:
>> frebe73@gmail.com wrote:
>>
>>>> Fair enough.  But in that case you have at least committed to using a
>>>> SQL DBMS, and that it will be from one of the major players in the
>>>> market.  That is somewhat different from RCM's position, which is (as I
>>>> understand it) that it should be trivial to unplug your SQL DBMS and
>>>> replace it by something else that doesn't even use SQL.
>>>
>>> The big questing is: Why do you want to unplug the SQL DBMS? It is very
>>> likely that the application programming language will be replace long
>>> before SQL is replaced. In that case, all work to decouple the the
>>> application from the DBMS is wasted. The productivity using an embedded
>>> approach (LAMP for example) is much higher than an layered/decoupled
>>> approach. If you make the decision to take this extra cost you need to
>>> be pretty sure that your application programming language will survive
>>> longer than SQL.
>>
>>
>> In my world there are two distinct types of application programming:
>> user interface application programming, and database application
>> programming.  It makes sense to embed SQL in the database code for the
>> reasons you give, but not in the UI code.  The UI is the most likely
>> bit to change in the near future, as we respond to the prevailing
>> tastes of the user community ("we want it
>> GUI-based/browser-based/mobile-based/...")  The database part OTOH may
>> not need to change for a long time, provided it performs well and
>> serves the UI well.  The interface between the UI and the database is
>> at the level  of business functions (e.g. "create an order", "produce
>> bills for this month", etc.) and is typically an API.
>>
>> One could argue that to the UI programmer, the database is a "bit
>> bucket" (very ugly term) of which he/she needs to know little.
>> However, the UI is probably only 10-20% of the code, with 80-90% being
>> the database application code - and to write this well you need to know
>> your DBMS.
> 
> Actually, you have that backward. In my experience, the combination of 
> exception-handling and user-interface code account for well over 90% of 
> the code in a typical 3gl/4gl application.

Agreed - UIs always take far more code to produce than database or 
server side applications. They tend to require more detailed thread 
handling too, so as to ensure responsiveness and over all user experience.

0
news261 (167)
6/1/2006 6:52:16 PM
Thank you for your feedback...

<<This is urban myth. SQL is widely criticised for its NULL and
duplicate
treatment. There is several more little annoying inconsistencies. >>
"myth" seems a strong word to me...It's true that SQL very apparent
drawbacks consists of poor duplicates treatment and poor handling of
missing data (NULL) but I do not believe these are the worst.  Other
drawbacks appear more troubling to me into handling better relational
requirements are the fact that SQL neither correctly support domain
definition, nor it implements any real coherence of what relational
data types are.
The main impact is that a better integrity preservation, a core issue,
becomes very difficult to implement.
<<This is what makes SQL hard to replace by a superior language. Keep
in
mind that some widely sucessful SQL features like "group-by" are
 ad-hock and are not part of the relational model.>>

<< I doubt naive OO method would contribute anything. If you want
in-depth
 theory of inheritance, classification then check up formal concept
 analysis (Uta Priss has written a nice survey article).>>

Thank you for this source of information.  I will check it as soon as I
get a chance.  I do not using OO in a *replacement* perspective of SQL.
 I was more wandering about what features distinctive of OO could bring
a better handling of a relational implementation such as in memory
representation of RTables (which you will convene I hope is not the
same thing).

Thank you for your input.

Mikito Harakiri wrote:
> Cimode wrote:
> > In a word, I am
> > under the impression that SQL (which was not initially thought of as it
> > is now) is becoming a limitation of the relational model.
>
> This is urban myth. SQL is widely criticised for its NULL and duplicate
> treatment. There is several more little annoying inconsistencies.
> That's about it. On practice, I fire SQL query and rarely get a
> surprising result that can be attributed to SQL deficiency.
>
> This is what makes SQL hard to replace by a superior language. Keep in
> mind that some widely sucessful SQL features like "group-by" are
> ad-hock and are not part of the relational model.
>
> > Which is why
> > a question may be asked which is: can OO bring something to that?   I
> > kept hearing about OO fuss about so many years that I am interested now
> > as what it may concretely bring to relational implementation... For
> > instance inheritance is something that may prove extremely useful in
> > the implementation of subtype/supertype RTables.
>
> I doubt naive OO method would contribute anything. If you want in-depth
> theory of inheritance, classification then check up formal concept
> analysis (Uta Priss has written a nice survey article). Formal concept
> analysis provides a nice set-theoretic model for many OO artifacts such
> as multiple inheritance, for instance.

0
cimode (135)
6/1/2006 7:06:40 PM
CMCC wrote:
> Marshall wrote:
> >
> > The reason why you see crap like this is because it is being
> > written by application developers.
>
> As an application developer I don't recognize myself in it.

Ah .... I stand corrected. IF a person is an application developer,
and knows nothing more than application development, and
moves into the field of data management, and doesn't recognize
it as a distinct field and/or simply chooses to treat this new
field in exactly the same way as the previous one, THEN
you get what I'm describing. That's considerably more
qualified that what I originally wrote; please excuse my
lack of precision.


> > And, if they do so, it would be poetic justice if the
> > programmers being born today trash all their work
> > in favor of some new fad.
>
> I try to hope the next generation wil get it right, but
> i think a new fads will replace the ones we have now.

I too have some hope, but not necessarily expectation.


> I'm waiting for Dynamic Hyperoriented XML (or.. is it alrady here?)

Ha!


> (I was not ignoring you... i think we simply agree)

It appears so.


Marshall

0
6/1/2006 7:12:38 PM
Marshall wrote:

please excuse my
> lack of precision.
> 

I will tell no one!

Carlos

0
c_jackal (9)
6/1/2006 7:31:25 PM
"Christian Brunschen" <cb@festis.df.lth.se> wrote in message
news:e5mraq$j66$1@news.lth.se...
> In article <lsBfg.3076$%86.209@trndny04>,
> David Cressey <dcressey@verizon.net> wrote:
> >
> >"Christian Brunschen" <cb@festis.df.lth.se> wrote in message
> >news:e5mir9$gug$1@news.lth.se...
> >> For a trivial example, consider an application that needs to somehow
> >> authenticate users [ ... ]
> >
> >What makes the example trivial?  Do you mean trivial in the sense that
> >mathematicians use the word, in the sense that engineers use the word,
or
> >in the sense that common parlance uses the word?
>
> In a very loose common parlance sense of the example being easy to come up
> with, not being contrived and thus something that people do occasionally
> encounter.
>

I think that in common parlance,  trivial means "unimportant"  and not
"easy".


0
dcressey (35)
6/1/2006 7:31:31 PM
Tony Andrews wrote:
> One could argue that to the UI programmer, the database is a "bit
> bucket" (very ugly term) of which he/she needs to know little.
> However, the UI is probably only 10-20% of the code, with 80-90% being
> the database application code - and to write this well you need to know
> your DBMS.

In my own limited experience UI is far more complex than that.

> This is a lot different from RCM's stance (as I understand it), which
> is that even the developer writing the database code - the "guts" of
> the data processing - shouldn't need to know anything about the DBMS.
> I don't agree with this.
> 

My interpretation of RCM's stance is that one should simply decouple 
database from the domain model in the similar fashion as one should 
decouple UI from the domain model. This then makes the domain logic pure 
and independent of persistence as well as UI representational technology.

Obviously, in such decoupled architecture everything else is detail when 
seen from any part. To UI both domain and storage are irrelevant, the 
domain doesn't care about UI or storage, and storage doesn't care about 
the other two, yet the three function impeccably due to mappers between 
them.

Why is that good? To me primarily because it distills the domain logic 
(which is the core problem of the application) and reduces complexity 
because each part of the triad (domain, storage and UI) is fairly 
independent and can be developed/analyzed/maintained in the isolation.
The changeability benefit is secondary, especially in case of storage 
(UI does change often), albeit not insignificant - one could envision 
scenarios where it is called for, and I have actually witnessed switch 
from the SQL database which had SP-s to the inferior one which didn't 
support SPs.

Sasa
0
sasa555 (109)
6/1/2006 7:33:42 PM
Robert Martin wrote:
> On 2006-05-31 11:09:05 -0500, "topmind" <topmind@technologist.com> said:
>
> > This sounds like the "RDBMS is a low-level tool/service" argument. I
> > have to disagree. One can treat it merely as a filing system, but can
> > also treat it as a sophisticated modeling tool.
>
> Agreed.  You CAN use the RDBMS as the application programming language.


This is not really what I meant. It is a matter of partitioning between
DB-centric stuff and app language stuff. Apps work best when each does
the task that it is best at. Using the app language to manage
taxonomies/classifications, track/store tons of attributes, perform
look-ups, create complex or large data structures are example of things
that apps don't do as well as a DB or table engine.


>  However, if you do that, then you have made the decision about
> application programming language.  You can't defer this decision very
> long.

I am not quite sure what this "defer decision" is really about. The DB
is usually assumed available, at least in my domain.

>
>
> --
> Robert C. Martin (Uncle Bob)  | email: unclebob@objectmentor.com

-T-

0
topmind (2124)
6/1/2006 7:39:26 PM
"Cimode" <cimode@hotmail.com> wrote in message
news:1149188800.056087.159770@h76g2000cwa.googlegroups.com...
> Thank you for your feedback...
>
> <<This is urban myth. SQL is widely criticised for its NULL and
> duplicate
> treatment. There is several more little annoying inconsistencies. >>
> "myth" seems a strong word to me...It's true that SQL very apparent
> drawbacks consists of poor duplicates treatment and poor handling of
> missing data (NULL) but I do not believe these are the worst.  Other
> drawbacks appear more troubling to me into handling better relational
> requirements are the fact that SQL neither correctly support domain
> definition, nor it implements any real coherence of what relational
> data types are.
> The main impact is that a better integrity preservation, a core issue,
> becomes very difficult to implement.
>

I'm not following the above.  Bad duplicate treatment can be avoided by
judicious use of primary keys and the "distinct" feature.  NULLS are handled
pretty well by SQL,  to the extend that SQL deals with them at all.  OTOH,
some of the SQL DBMS products don't deal with missing data very well.

But what really baffles me is "lack of domain definition"?  CREATE DOMAIN
seems pretty straightforward to me...
am I missing something?


0
dcressey (35)
6/1/2006 7:39:36 PM
Marshall wrote:
> There's a severe problem with that logic, though.
> 
> If you want to build a layer to wrap a variety of different storage
> mechanisms, that layer *cannot* be any more powerful than
> the weakest mechanism you want to layer on top of. Which
> means your very high level, very powerful SQL dbms will
> be stuck at the level of the stupidest file store ever invented.

I beg to disagree with that.
If the wrapper/mapper is written to abstract the needs of the client, 
its representation can fully leverage the power of the specific storage 
regardles of any other implementation.

Of course, such wrapper offers very specific services to its client, 
thus hiding the full richness of the strongest storage mechanism of the 
bunch. However this is OK, as the client (the domain) has very specific 
needs and that is precisely the purpose of the wrapper - to abstract 
those needs which then incidentally allows implementational variations.

Sasa
0
sasa555 (109)
6/1/2006 7:40:25 PM
In article <ngHfg.80$_F6.20@trndny03>,
David Cressey <dcressey@verizon.net> wrote:
>
>I think that in common parlance,  trivial means "unimportant"  and not
>"easy".

From the dictionary included with Mac OS X:

<quote>

Dictionary	

trivial adjective of little value or importance : huge fines were imposed 
for trivial offenses | trivial details. ? (of a person) concerned only 
with trifling or unimportant things. ? Mathematics denoting a subgroup 
that either contains only the identity element or is identical with the 
given group. DERIVATIVES triviality noun ( pl. -ties) trivially adverb 
ORIGIN late Middle English (in the sense [belonging to the trivium] ): 
from medieval Latin trivialis, from Latin trivium (see trivium ).


Thesaurus	

trivial adjective 1 trivial problems unimportant, banal, trite, 
commonplace, insignificant, inconsequential, minor, of no account, of no 
consequence, of no importance; incidental, inessential, nonessential, 
petty, trifling, trumpery, pettifogging, footling, small, slight, little, 
inconsiderable, negligible, paltry, nugatory; informal piddling, picayune, 
nickel-and-dime, penny-ante; trademark Mickey Mouse. antonym important, 
significant, life-and-death. 2 I used to be quite a trivial person 
frivolous, superficial, shallow, unthinking, airheaded, featherbrained, 
lightweight, foolish, silly, trite. antonym profound, serious.

</quote>


So, yes, you're right, my use of 'trivial' in that context was incorrect. 
I learn something new every day. 

// Christian Brunschen
0
cb5180 (38)
6/1/2006 7:42:47 PM
Sasa wrote:

> Tony Andrews wrote:
> 
>> One could argue that to the UI programmer, the database is a "bit
>> bucket" (very ugly term) of which he/she needs to know little.
>> However, the UI is probably only 10-20% of the code, with 80-90% being
>> the database application code - and to write this well you need to know
>> your DBMS.
> 
> 
> In my own limited experience UI is far more complex than that.
> 
>> This is a lot different from RCM's stance (as I understand it), which
>> is that even the developer writing the database code - the "guts" of
>> the data processing - shouldn't need to know anything about the DBMS.
>> I don't agree with this.
>>
> 
> My interpretation of RCM's stance is that one should simply decouple 
> database from the domain model in the similar fashion as one should 
> decouple UI from the domain model. This then makes the domain logic pure 
> and independent of persistence as well as UI representational technology.
> 
> Obviously, in such decoupled architecture everything else is detail when 
> seen from any part. To UI both domain and storage are irrelevant, the 
> domain doesn't care about UI or storage, and storage doesn't care about 
> the other two, yet the three function impeccably due to mappers between 
> them.
> 
> Why is that good? To me primarily because it distills the domain logic 
> (which is the core problem of the application) and reduces complexity 
> because each part of the triad (domain, storage and UI) is fairly 
> independent and can be developed/analyzed/maintained in the isolation.
> The changeability benefit is secondary, especially in case of storage 
> (UI does change often), albeit not insignificant - one could envision 
> scenarios where it is called for, and I have actually witnessed switch 
> from the SQL database which had SP-s to the inferior one which didn't 
> support SPs.

This 'domain logic' to which you refer. What does it do that is not 
entering, manipulating, reporting or deriving data? Of that which 
remains, what does not interface with the external world through some 
device or another?
0
bbadour (434)
6/1/2006 7:45:40 PM
David Cressey wrote:

> "Cimode" <cimode@hotmail.com> wrote in message
> news:1149188800.056087.159770@h76g2000cwa.googlegroups.com...
> 
>>Thank you for your feedback...
>>
>><<This is urban myth. SQL is widely criticised for its NULL and
>>duplicate
>>treatment. There is several more little annoying inconsistencies. >>
>>"myth" seems a strong word to me...It's true that SQL very apparent
>>drawbacks consists of poor duplicates treatment and poor handling of
>>missing data (NULL) but I do not believe these are the worst.  Other
>>drawbacks appear more troubling to me into handling better relational
>>requirements are the fact that SQL neither correctly support domain
>>definition, nor it implements any real coherence of what relational
>>data types are.
>>The main impact is that a better integrity preservation, a core issue,
>>becomes very difficult to implement.
> 
> I'm not following the above.  Bad duplicate treatment can be avoided by
> judicious use of primary keys and the "distinct" feature.  NULLS are handled
> pretty well by SQL,  to the extend that SQL deals with them at all.  OTOH,
> some of the SQL DBMS products don't deal with missing data very well.
> 
> But what really baffles me is "lack of domain definition"?  CREATE DOMAIN
> seems pretty straightforward to me...
> am I missing something?

I think you are missing the part where a domain is an arbitrary data 
type complete with its own set of operations. You seem to have confused 
the relational domain with the rudimentary aliasing facility that 
actually made it into SQL using a similar name.
0
bbadour (434)
6/1/2006 7:48:42 PM
Robert Martin wrote:
> On 2006-05-31 11:09:05 -0500, "topmind" <topmind@technologist.com> said:
>
> > I have not found a way to use "coupling and cohesion" as an objective
> > metric.
>
> I have.  Read my papers on the topic.

I have. They don't answer the outstanding issues. Plus, device driver
examples extrapolate very poorly to my domain.

>
> If module A depends on module B, then A is coupled to B.

There are fuzzy areas when measuring "depends on".

> If B canges a
> lot, then those changes impact upon A.

Part of my disagreements with many OO fans is in regard to change
probabilities. They seem to assume patterns to change that do not match
my own observations. I suspect they are biased by pro-OO material
rather than rely on actual observations.

When I use my change estimates, OO looks like the worse choice,
hard-wiring in hierarchies and mutually-exclusive-based taxonomies. The
change patterns that polymorphism and inheritance rely on are simply
not common enough in the real world that I observe, and the few times
they are, are not knowable in advanced.

I agree that change analysis is important, but it is a black art at
this point. My probability-of-change estimates are different than
yours, etc.

No approach is magically optimized for all possible changes. Tradeoffs
must be weighed like investors picking stocks/bonds. Programming is
gambling/investing.

> If A does not need to change,
> but is forced to change because of B, then we have coupling that we'd
> like to get rid of.  Creating an interface IAusesB that B implement and
> A uses isolates A from many of the changes to B.
>

>
> --
> Robert C. Martin (Uncle Bob)  | email: unclebob@objectmentor.com

-T-

0
topmind (2124)
6/1/2006 7:49:32 PM
Sasa wrote:

> Marshall wrote:
> 
>> There's a severe problem with that logic, though.
>>
>> If you want to build a layer to wrap a variety of different storage
>> mechanisms, that layer *cannot* be any more powerful than
>> the weakest mechanism you want to layer on top of. Which
>> means your very high level, very powerful SQL dbms will
>> be stuck at the level of the stupidest file store ever invented.
> 
> 
> I beg to disagree with that.
> If the wrapper/mapper is written to abstract the needs of the client, 
> its representation can fully leverage the power of the specific storage 
> regardles of any other implementation.
> 
> Of course, such wrapper offers very specific services to its client, 
> thus hiding the full richness of the strongest storage mechanism of the 
> bunch. However this is OK, as the client (the domain) has very specific 
> needs and that is precisely the purpose of the wrapper - to abstract 
> those needs which then incidentally allows implementational variations.

With all due respect, Sasa, decomposing an application into cohesive 
components is not at all the same as separating database access to 
enable swapping out a dbms on a whim nor is it the same as establishing 
a layer to separate database access from everything else.
0
bbadour (434)
6/1/2006 7:53:42 PM
On 2006-05-31 09:45:00 -0500, "Marshall" <marshall.spight@gmail.com> said:

> Robert Martin wrote:
>> 
>> I disagree with this analogy.  The RDBMS is a mechanisms for storing,
>> accessing, reporting, data.
> 
> If your understanding of the role of the DBMS only extends that
> far, then no wonder you misunderstand so much.
> 
> Storage is an incidental feature of a DBMS. A thing can be
> a DBMS and not do persistence.
> 
> Your use of the word "access" again reinforces the idea
> that you view the DBMS as merely a storage mechanism.
> 
> That you completely fail to mention the *primary* uses
> of a DBMS is telling. Structure, integrity, and manipulation
> are the central strengths of a DBMS. The pride of
> application developers (or simply their lack of education)
> makes them want to reserve these functions for their
> application code, because that's the only hammer they
> know how to swing well. But application code is an
> inferior tool for these.

Dear Marshall,

The soft insinuation that I am ignorant, is really just an ad-hominem 
argument.  The gentle implication that I am part of an arrogant and 
ignorant group is also an ad-hominem.  I encourage you to avoid such 
arguments since you are quite completely ignorant of my knowledge of 
the subject.

In the midst of the ad-hominems I think you made a good point.  I did, 
in fact, underlay the role of the DBMS.  I don't think you followed 
through on that point though.  In what way does the importance of the 
DBMS impact on my assertion that the application design should not know 
about the details of the DBMS.  Do the attributes of data integrity and 
manipulation mean that the application code should strongly couple 
itself to the details of the DBMS?

>> That mechanism can be implemented many
>> different ways and need not even be an RDB.  The application code
>> defines what the program does with the data.
> 
> It appears that the OOPL mantra of "state and behavior" has
> gotten you to the point of believing that data structures and
> imperative functions are the only way to work with a computer.
> You may wish to consider the possibility that this is a very
> limiting, perhaps even stunting way to look at the world.

I'm an old hand at many different languages and programming schemes.  
Along with all the standard application languages, I've studied and 
used languages like Prolog, Forth, Snobol, etc, etc, etc.  I drew my 
first ER diagram over 20 years ago, when I already had 15 years of 
exeperience behind me, and have since used many different RDBs, in many 
different environments.  I have designed reactive systems driven by 
triggers, and I have designed imperative systems driven by top down 
functions.   I have worked in MIS environments and embedded real-time 
environments.  I have worked on shrink-wrapped software, and 
mathematical modeling software.

In short, if my way of viewing the world is "stunting" it is not 
because I haven't been learning as much as I can about as much of this 
industry as I can for the last 35 years.

Oh and by the way, that last paragraph was also a subtle ad-hominem 
argument about what "it appears" my opinions might be and how they 
might be stunting.

SO.......

Let's see if we can drive this back to substance.  Instead of telling 
me all the things that are wrong with my upbrining, tell me what's 
wrong with my assertion that application design should be decoupled 
from database design.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/1/2006 8:05:10 PM
Dmitry A. Kazakov wrote:
> Operations on functions (subprograms):

These are easily defined in the realtional world (where we consider a
function as a relation)

> 1. Mapping (call to) the tuple of arguments to the tuple of results
>
>    Map : f x x1 x  x2 x ... x xN -> y1 x y2 x ... x yN

Calling a function f(x,y) with two arguments x=1 and y=2 is relational
join of three relations:

'z=f(x,y)' /\ `x=1` /\ `y=2`

projected to attribute z.

> 2. Composition:
>
>    o : f1 x f2 -> f1 (f2 (x))

Composition of y=f(x) and z=g(y) is relational join

'y=f(x)' /\ 'z=g(y)'

projected to attributes x and z.

> 3. Comparison
>
>    = : f1 x f2 -> Boolean

Comparison is the symmetric difference of the two relations. It is a
relation, not boolena value. Empty result means that the relations are
identical.

> 4. Copy (for marshaling, closures etc)
>
>    := : f -> f

Copying is not a logical operation. Yet it corresponds to a trivial
relational query that outputs the same relation.

> 5. Convolution
>
>    * : f1 x f2 x sum x prod x inv -> sum (prod (f(x), g(inv (x)))

In your description I don't see how convolution is different from
composition.

> 6. Extension
>
> and so on

What is extension?

> >> But that is rather trivial and uninteresting.
> >
> > Well, it's hardly trivial for numbers, why it suddenly becomes trivial
> > for functions?
>
> Because in this particular case function is a value and values are outside
> the language scope. Somewhere in the application domain exists 2. So there
> does sine. You don't care what they are. You only need some object to
> represent them. Let the bit pattern 0x1 represent 2 and 0x2 do sine. End of
> story.

I don't understand this gibberish.

> Don't you see any difference between mathematical constructs and
> programming language objects?

Yes. Programming language objects are bastardized counterparts of
mathematical constructs.

0
6/1/2006 8:07:49 PM
Robert Martin wrote:
> what's wrong with my assertion that application design should be decoupled
> from database design.

Assertion alone is worthless without solid method that supports it. And
what method OO propellerheads suggest? OR mappers (which essentially
are reincarnated OODBMS)? What I am supposed to learn 20 something
ad-hock mapping types instead of 6 clean relational operators? Or worse
yet, some "pattern"?

0
6/1/2006 8:26:02 PM
On 2006-05-31 11:31:29 -0500, Bob Badour <bbadour@pei.sympatico.ca> said:

> Robert Martin wrote:
> 
>> On 2006-05-30 06:31:53 -0500, "Erwin" <e.smout@myonline.be> said:
>> 
>>> Little point in preaching to the chuiar of course (how do you spell
>>> that damn word ?).
>>> 
>>> Go tell this on an Otherwise Oriented forum, you'll get dawnbashed.
>>> 
>>> That said, application code is still highly important because it's
>>> needed to fill all the holes that current dbms's still leave wide open
>>> in the area of constraint enforcement.
>> 
>> This statement is fascinating.  It takes the view that the majority of 
>> the system is DB and that application code simply fills the cracks.  
>> The DB represents the bricks and the application code is the mortar.
>> 
>> I disagree with this analogy.
> 
> Which is highly indicative of your profound ignorance, which was noted 
> previously.

Ah!  If I disagree, I am ignorant.  I see.  Now, can we get past the 
ad=hominem arguments about my personal character and get back to the 
argument at hand?  WHY is it ignorant to disagree that the DB is the 
brick, and the app is the mortar?


> The RDBMS is a mechanisms for storing,
>> accessing, reporting, data.  That mechanism can be implemented many 
>> different ways and need not even be an RDB.
> 
> If one is stupid, ignorant or has no choice, I suppose one might use 
> something different. The RDBMS is also a mechanism for manipulating 
> data, for security, for integrity, for derivation, for all-round 
> management -- as the name implies.

Sigh.  Then I suppose all OS designers are stupid and ignorant, because 
they certainly COULD have build the directory file structure on top of 
an RDB had they wanted to.  But none have done this.  So, they must all 
be stupid and ignorant.

> 
>    The application code
>> defines what the program does with the data.
> 
> Other than enter, manipulate, report and derive, what does one do with data?

One makes decisions based upon it.  One transforms it from one state to 
another.  One merges data streams together and divides data streams 
apart.

An RDBMS can sometimes be a wonderful tool to use in pursuit of these 
activities.  Other times it is not.

> [irrelevant and incorrect metaphors snipped]

Ah, so you are going with the "relevant" and "correct" metaphor of the 
bricks and mortar?  Please note that bricks and mortar produce static 
structures.  Indeed it is the nature of bricks and mortar to be static. 
 On the other hand, it is the nature of software to be dynamic.  So I 
think the metaphor might have a very slight flaw.  But then, I'm stupid 
and ignorant, so you could just ignore my incoherent rantings.  Please.
>> 
>> The story may be true, but I'm not sure I get the point.  Frankly, it 
>> IS the responsibility of the application to enforce integrity.  Oh, the 
>> DB can enforce it while the data is in the warehouse, but the data 
>> comes out of the warehouse, gets transported all over the place, gets 
>> transformed in many different ways into many different products, gets 
>> presented to many different customers and put into many different 
>> systems, and for all these activities it is the APPLICATION that must 
>> enforce the integrity of the data.
> 
> Once again, you expose your ignorance.

ONCE AGAIN!  Oh will the ignorance never cease?  Can't these idiot 
application programmers see the beauty and power of the DB?  Don't they 
understand?  They just don't get it.  They just don't get it.  They are 
ignorant and stupid.

> If you remove the data from the data management system, obviously, you 
> force yourself to re-invent other tools to manage the data--however 
> poorly. It strikes me as rather stupid to choose the wrong tool for the 
> job, though.

Hmmm.  So your solution is that the data should never be removed from 
the DBMS?  I should never send a credit request transaction to a credit 
check company because the data would have to leave the DBMS?  I should 
never print a purchase order because the data would have to leave the 
DMBS?  I should never present a customer record on a web page because 
the data would have to leave the DBMS?
> 
> 
>    The DB loses control once the data
>> is out of the warehouse.
> 
> Here, you expose sloppy thinking.

Ignorant, Stupid, AND SLOPPY!  Heavens!  What is this industry coming 
to.  Ye GODS, why do we have to deal with these moronic people who post 
OPINIONS on this newsgroup.

> A database is simply a set of facts, which renders your sentence nonsense.

Sorry.  Let me put the MS back on the end of the DB so that your 
fragile sensibilities aren't harmed.

     The DBMS loses control once the data is out of the warehouse

OK, now we can continue.

> If one were charitable, one might substitute 'data management system' 
> where you put DB, but then the statement would become unremarkable and 
> pointless.

I think the point is that once the data has left the MS it is the 
application program that is responsible for maintaining it's integrity 
until such time as it can be put back into that MS, or another MS.

>> Clearly keeping the integrity of the data in the warehouse is 
>> important.  But that's not the whole story.  It's not even most of the 
>> story.
> 
> Yes, that's true. If the protagonist chooses at the outset to do stupid 
> things (ie. to manage the data without a management system, to travel 
> to an island full of dinosaurs, to catch the maneating 30 foot great 
> white shark etc.), then Act II generally follows the protagonist as he 
> struggles against the harmful consequences of his stupid choices, and 
> Act III culminates the story with the protagonist either overcoming his 
> stupidity or succumbing.
> 
> That makes for entertaining drama, but I wasn't aware that the goal of 
> computing science or information technology was to create drama or to 
> entertain ourselves, per se.

Sorry, I didn't follow that last metaphor.  I thought we were sticking 
with bricks and mortar.  Or I at least thought that one of your points 
was that it's a bad idea to take the data out from the control of the 
MS.

Or perhaps you are still reeling from my assertion that application 
programs should be designed to be so decoupled from the MS that the MS 
could be replaced without affecting the application.  Perhaps you could 
tell me why this notion is stupid, ignorant, and sloppy, if that is 
what you believe.

>> Finally, and this is critical to the understaning of my point, the code 
>> in which data integrity is specified IS application code.  It may be 
>> written in a special purpose DB language, or it may not.  But it is 
>> code that supports the application.
> 
> Code? Do you consider a well-formed formula code?

yes.

> Are logic predicates code?

yes.

> I am just curious what you define as code.

Code is something a computer can read, interpret, and execute.  
Something that is so unambiguous and formal that an automaton can 
follow it.

> If you define code to include everything, then your statement is true 
> if unremarkable and uninteresting.

Remember that my original statement is that application programs should 
be designed such that they are decoupled from the MS.  Clearly if you 
use the MS langauge to write the bulk of the application you are 
violating that principle.  So, the "critical" point that was lost was 
that if you code the aplication in the DBMS langauge, you have not 
decoupled from the DBMS.

-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/1/2006 8:28:14 PM
Robert Martin wrote:
> In an enterprise there is a large body of interelated data.  This data
> needs to be kept in one place, and in one form, in order to eliminate
> duplication and maintain integrity.
>
> In an enterprise there are many different applications.  Each
> application needs to manipulate a portion (or "view") of the data.
> Very few applications need to maniuplate ALL the data.
>
> The optimum structure for each application is local to it's particular
> function.

While I agree that data and behavior will never be unified, you lost me
here. Presumably having a "localized structure" requires a mapping
layer (enterprise <-> local). If that layer is trivial, then it can be
expressed in terms of the enterprise data anyway, and hopefully with
such mechanisms as Views.

If it's complex, then either the application lacks the ability to read
and manipulate the enterprise "structures," or it's a specialized tool.
Reports, batch programs, GUIs, etc. can all typically access at least
SQL DBMSs.

Maybe I'm misunderstanding what you mean by "optimum structures" and
how they relate to the enterprise data?

> the optimum structure for the data has to do with ALL the applications.
>  The structure of the data must make affordances for the most important
> applications, generally at the cost of inefficiency for those
> applications that are infrequent or less important.

Are you talking about denormalization in the enterprise database? The
most important applications are typically (at least in my experience)
those on the front lines with many users, and I don't often see a need
for them to deal with overly-localized "data structures".

> So, the design trade-offs for the applications are completely different
> from the design trade-offs for the data model.  Therefore unifying them
> is probably impossible.

The only one you've mentioned is efficiency, and both applications and
data model share some big concerns: concisely expressing business
requirements, sharing data between applications, having a common types
and business predicates, etc. I still don't see that a normalized
database is only of value from the point of view of the database; it
has a large impact on applications as well.

> To defend themselves developers export behavior out of the OODB and
> into the applications.  Eventually the OODB is denuded of behavior and
> becomes little more than a network database -- a pile of interelated
> data structures.  At which point it might as well be an RDB.

Except with an RDB you've have a lot more than a castrated OODB - cum -
network DB.

- erk

0
eric.kaun (62)
6/1/2006 8:37:48 PM
"Bob Badour" <bbadour@pei.sympatico.ca> wrote in message
news:uwHfg.16134$A26.374329@ursa-nb00s0.nbnet.nb.ca...
> David Cressey wrote:
>
> > "Cimode" <cimode@hotmail.com> wrote in message
> > news:1149188800.056087.159770@h76g2000cwa.googlegroups.com...
> >
> >>Thank you for your feedback...
> >>
> >><<This is urban myth. SQL is widely criticised for its NULL and
> >>duplicate
> >>treatment. There is several more little annoying inconsistencies. >>
> >>"myth" seems a strong word to me...It's true that SQL very apparent
> >>drawbacks consists of poor duplicates treatment and poor handling of
> >>missing data (NULL) but I do not believe these are the worst.  Other
> >>drawbacks appear more troubling to me into handling better relational
> >>requirements are the fact that SQL neither correctly support domain
> >>definition, nor it implements any real coherence of what relational
> >>data types are.
> >>The main impact is that a better integrity preservation, a core issue,
> >>becomes very difficult to implement.
> >
> > I'm not following the above.  Bad duplicate treatment can be avoided by
> > judicious use of primary keys and the "distinct" feature.  NULLS are
handled
> > pretty well by SQL,  to the extend that SQL deals with them at all.
OTOH,
> > some of the SQL DBMS products don't deal with missing data very well.
> >
> > But what really baffles me is "lack of domain definition"?  CREATE
DOMAIN
> > seems pretty straightforward to me...
> > am I missing something?
>
> I think you are missing the part where a domain is an arbitrary data
> type complete with its own set of operations. You seem to have confused
> the relational domain with the rudimentary aliasing facility that
> actually made it into SQL using a similar name.

I thought the diffence between a "domain" and a "type" was precisely that
types include operators while domains do not.



0
dcressey (35)
6/1/2006 8:43:43 PM
Robert Martin wrote:

> tell me what's 
> wrong with my assertion that application design should be decoupled 
> from database design.

If the logical code relies on ACID and CRUD, and the application obtains
these from behind a facade, and if you swap out the DB and put in another
one with different ACID or CRUD, you could introduce subtle bugs.

-- 
  Phlip

0
phlip20052 (146)
6/1/2006 8:48:28 PM
On 1 Jun 2006 13:07:49 -0700, Mikito Harakiri wrote:

> Dmitry A. Kazakov wrote:
>> Operations on functions (subprograms):
> 
> These are easily defined in the realtional world (where we consider a
> function as a relation)
> 
>> 1. Mapping (call to) the tuple of arguments to the tuple of results
>>
>>    Map : f x x1 x  x2 x ... x xN -> y1 x y2 x ... x yN
> 
> Calling a function f(x,y) with two arguments x=1 and y=2 is relational
> join of three relations:
> 
> 'z=f(x,y)' /\ `x=1` /\ `y=2`
> 
> projected to attribute z.

Where you get z for all possible x and y? Another problem is that this is 
untyped. You should add some constrains on x and y. You can do it 
externally, but it should be a function property. The third problem is that 
you need "=" for all things as well as literals for all things. It is a can 
of worms. Especially function literals aren't easy. What is a literal of 
sine?

>> 2. Composition:
>>
>>    o : f1 x f2 -> f1 (f2 (x))
> 
> Composition of y=f(x) and z=g(y) is relational join
> 
> 'y=f(x)' /\ 'z=g(y)'
> 
> projected to attributes x and z.

Same problem as before.

>> 3. Comparison
>>
>>    = : f1 x f2 -> Boolean
> 
> Comparison is the symmetric difference of the two relations. It is a
> relation, not boolena value. Empty result means that the relations are
> identical.

This is non-constructive. Are you going to compare all inputs and outputs? 
Even if they model uncountable sets?

>> 4. Copy (for marshaling, closures etc)
>>
>>    := : f -> f
> 
> Copying is not a logical operation.

It is. You should consider the computational state as an additional 
parameter:

":=" : f x S -> f x S

> Yet it corresponds to a trivial
> relational query that outputs the same relation.
> 
>> 5. Convolution
>>
>>    * : f1 x f2 x sum x prod x inv -> sum (prod (f(x), g(inv (x)))
> 
> In your description I don't see how convolution is different from
> composition.

You have some free arguments and some bound arguments. Bound arguments run 
through some set. It can be specified through relations, of course. 
Anything can be.

>> 6. Extension
>>
>> and so on
> 
> What is extension?

This is when you add some prologue and/or epilogue to a subprogram. It is 
especially important in generic programming and for things like 
constructors and destructors. In general, when you want to enforce some 
semantics on the resulting function.

>>>> But that is rather trivial and uninteresting.
>>>
>>> Well, it's hardly trivial for numbers, why it suddenly becomes trivial
>>> for functions?
>>
>> Because in this particular case function is a value and values are outside
>> the language scope. Somewhere in the application domain exists 2. So there
>> does sine. You don't care what they are. You only need some object to
>> represent them. Let the bit pattern 0x1 represent 2 and 0x2 do sine. End of
>> story.
> 
> I don't understand this gibberish.

Would "sin" be better?

>> Don't you see any difference between mathematical constructs and
>> programming language objects?
> 
> Yes. Programming language objects are bastardized counterparts of
> mathematical constructs.

Right. The problem is that mathematical constructs modeled in a 
computational framework might be too large for any finite state machine. So 
an uncountable set of real numbers is replaced by a finite set of 
intervals. That's the gibberish in which I am talking. We can't have all 
the table of real-valued functions. The size of this table is aleph-2! 
Where you find a hard disk of this size? Fortunately, from all this table, 
today, I need only sine. So I say let sine be denoted as 0x2.

Nevertheless, nothing prevents us to formalize these bastards and use 
mathematical rigour to handle them. Disagree?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/1/2006 8:57:25 PM
Thank you for your feedback...

<<Bad duplicate treatment can be avoided by
 judicious use of primary keys and the "distinct" feature>>
Absolutely. However these are turnaround solutions to insure the
integrity of data that are to implemented in applicative DBMS code when
they should be dealt with by the DBMS.  As a result, during system life
cycle what should be done once is often done each time a new view is
defined which defeats the purpose of a DBMS.  A practical problem
arising happens for instance when a developper leaves a company.  If
this developper has participated in the design (or lack of design)
process then this developper is probably aware of all the special
conditions and features he should add (DISTINCT, IS NULL IS NOT NULL)
to make count results correct.  But as soon as this developper leaves
the company his knowledge often get lost which in most cases will make
the next generation of count queries return false results because the
new developper will not be necessarily aware of the conditions required
to make results correct.  In a word the use of features such as
distinct are already meaning a failure on a relational standpoint.  In
the case of DISTINCT, their suggested use was made by Codd as a warning
about that limitation.

<<NULLS are handled pretty well by SQL>>
The problem is not whether NULL values are well handled by SQL, the
problem is that NULL values are SQL's only way of representing missing
information and that this way is a poor one because relational
predicate logic suporting relational model does not support on three
valued logic on which SQL NULLS are essentially based.

<<OTOH, some of the SQL DBMS products don't deal with missing data very
well>>
True, but I would phrase it otherwise.  I would rather say that some
implementation are more *aware* of SQL limitations to handle missing
data and that some implementation have a higher automation of getaounrd
solutions/

<< But what really baffles me is "lack of domain definition"?  CREATE
DOMAIN
 seems pretty straightforward to me... am I missing something?>>
Unfortunately, CREATE DOMAIN is a relational domain but a SQL domain
which is not the same.  First they support only primitive data types
(date/time where created only in SQL92).  Second, SQL domain data types
are only derivation of primitive types.  Additionally, SQL domains do
not allow to define user defined operators..As a proof of this
limitation several SQL DBMS do not implement can not for instance
define a table according using as a data type another table (and they
can even less define operators for these tables).



David Cressey wrote:
> "Cimode" <cimode@hotmail.com> wrote in message
> news:1149188800.056087.159770@h76g2000cwa.googlegroups.com...
> > Thank you for your feedback...
> >
> > <<This is urban myth. SQL is widely criticised for its NULL and
> > duplicate
> > treatment. There is several more little annoying inconsistencies. >>
> > "myth" seems a strong word to me...It's true that SQL very apparent
> > drawbacks consists of poor duplicates treatment and poor handling of
> > missing data (NULL) but I do not believe these are the worst.  Other
> > drawbacks appear more troubling to me into handling better relational
> > requirements are the fact that SQL neither correctly support domain
> > definition, nor it implements any real coherence of what relational
> > data types are.
> > The main impact is that a better integrity preservation, a core issue,
> > becomes very difficult to implement.
> >
>
> I'm not following the above.  Bad duplicate treatment can be avoided by
> judicious use of primary keys and the "distinct" feature.  NULLS are handled
> pretty well by SQL,  to the extend that SQL deals with them at all.  OTOH,
> some of the SQL DBMS products don't deal with missing data very well.
>
> But what really baffles me is "lack of domain definition"?  CREATE DOMAIN
> seems pretty straightforward to me...
> am I missing something?

0
cimode (135)
6/1/2006 9:00:37 PM
Mikito Harakiri wrote:

> Assertion alone is worthless without solid method that supports it.

Be prepared to respond with whatever solid method you used to support your
own current technique. ;-)

> And
> what method OO propellerheads suggest? OR mappers (which essentially
> are reincarnated OODBMS)? What I am supposed to learn 20 something
> ad-hock mapping types instead of 6 clean relational operators? Or worse
> yet, some "pattern"?

An application should have its SQL statements in only a few modules, and
all others should be SQL-free.

Note in my statement, you can replace SQL with GUI, XML, ORB, etc, to
generally the same effect. The point of modules is to isolate and
encapsulate.

Is that so hard?

-- 
  Phlip

0
phlip20052 (146)
6/1/2006 9:02:26 PM
Agreed..There may be some confusion.
Bob Badour wrote:
> David Cressey wrote:
>
> > "Cimode" <cimode@hotmail.com> wrote in message
> > news:1149188800.056087.159770@h76g2000cwa.googlegroups.com...
> >
> >>Thank you for your feedback...
> >>
> >><<This is urban myth. SQL is widely criticised for its NULL and
> >>duplicate
> >>treatment. There is several more little annoying inconsistencies. >>
> >>"myth" seems a strong word to me...It's true that SQL very apparent
> >>drawbacks consists of poor duplicates treatment and poor handling of
> >>missing data (NULL) but I do not believe these are the worst.  Other
> >>drawbacks appear more troubling to me into handling better relational
> >>requirements are the fact that SQL neither correctly support domain
> >>definition, nor it implements any real coherence of what relational
> >>data types are.
> >>The main impact is that a better integrity preservation, a core issue,
> >>becomes very difficult to implement.
> >
> > I'm not following the above.  Bad duplicate treatment can be avoided by
> > judicious use of primary keys and the "distinct" feature.  NULLS are handled
> > pretty well by SQL,  to the extend that SQL deals with them at all.  OTOH,
> > some of the SQL DBMS products don't deal with missing data very well.
> >
> > But what really baffles me is "lack of domain definition"?  CREATE DOMAIN
> > seems pretty straightforward to me...
> > am I missing something?
>
> I think you are missing the part where a domain is an arbitrary data
> type complete with its own set of operations. You seem to have confused
> the relational domain with the rudimentary aliasing facility that
> actually made it into SQL using a similar name.

0
cimode (135)
6/1/2006 9:03:13 PM
David Cressey wrote:

> "Bob Badour" <bbadour@pei.sympatico.ca> wrote in message
> news:uwHfg.16134$A26.374329@ursa-nb00s0.nbnet.nb.ca...
> 
>>David Cressey wrote:
>>
>>
>>>"Cimode" <cimode@hotmail.com> wrote in message
>>>news:1149188800.056087.159770@h76g2000cwa.googlegroups.com...
>>>
>>>
>>>>Thank you for your feedback...
>>>>
>>>><<This is urban myth. SQL is widely criticised for its NULL and
>>>>duplicate
>>>>treatment. There is several more little annoying inconsistencies. >>
>>>>"myth" seems a strong word to me...It's true that SQL very apparent
>>>>drawbacks consists of poor duplicates treatment and poor handling of
>>>>missing data (NULL) but I do not believe these are the worst.  Other
>>>>drawbacks appear more troubling to me into handling better relational
>>>>requirements are the fact that SQL neither correctly support domain
>>>>definition, nor it implements any real coherence of what relational
>>>>data types are.
>>>>The main impact is that a better integrity preservation, a core issue,
>>>>becomes very difficult to implement.
>>>
>>>I'm not following the above.  Bad duplicate treatment can be avoided by
>>>judicious use of primary keys and the "distinct" feature.  NULLS are
> 
> handled
> 
>>>pretty well by SQL,  to the extend that SQL deals with them at all.
> 
> OTOH,
> 
>>>some of the SQL DBMS products don't deal with missing data very well.
>>>
>>>But what really baffles me is "lack of domain definition"?  CREATE
> 
> DOMAIN
> 
>>>seems pretty straightforward to me...
>>>am I missing something?
>>
>>I think you are missing the part where a domain is an arbitrary data
>>type complete with its own set of operations. You seem to have confused
>>the relational domain with the rudimentary aliasing facility that
>>actually made it into SQL using a similar name.
> 
> I thought the diffence between a "domain" and a "type" was precisely that
> types include operators while domains do not.

I am not sure where you got that idea. It is not my understanding at all.
0
bbadour (434)
6/1/2006 9:05:22 PM
On Fri, 02 Jun 2006 01:48:43 +0200, Bruno Desthuilliers wrote:

>> I don't think it could be consistent to have everything an object. 
> 
> Why so ?

"Everything" is a bad word. You might fall into an endless recursion.

My personal opinion is that we all should start to formalize things like
value, object, type, class etc in a way that would allow us to describe
OOPL, FPL and RMPL. Then we'll see what will emerge.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/1/2006 9:05:45 PM
phlip wrote:

> Mikito Harakiri wrote:
> 
> 
>>Assertion alone is worthless without solid method that supports it.
> 
> 
> Be prepared to respond with whatever solid method you used to support your
> own current technique. ;-)
> 
> 
>>And
>>what method OO propellerheads suggest? OR mappers (which essentially
>>are reincarnated OODBMS)? What I am supposed to learn 20 something
>>ad-hock mapping types instead of 6 clean relational operators? Or worse
>>yet, some "pattern"?
> 
> An application should have its SQL statements in only a few modules, and
> all others should be SQL-free.
> 
> Note in my statement, you can replace SQL with GUI, XML, ORB, etc, to
> generally the same effect. The point of modules is to isolate and
> encapsulate.
> 
> Is that so hard?

Define: few
0
bbadour (434)
6/1/2006 9:09:37 PM
<< I thought the diffence between a "domain" and a "type" was precisely
that
 types include operators while domains do not.>>
Actually you can view domains as user defined data types that are of a
user defined complexity and handling.  They certainly rely on operators
for operations such as intersect.


David Cressey wrote:
> "Bob Badour" <bbadour@pei.sympatico.ca> wrote in message
> news:uwHfg.16134$A26.374329@ursa-nb00s0.nbnet.nb.ca...
> > David Cressey wrote:
> >
> > > "Cimode" <cimode@hotmail.com> wrote in message
> > > news:1149188800.056087.159770@h76g2000cwa.googlegroups.com...
> > >
> > >>Thank you for your feedback...
> > >>
> > >><<This is urban myth. SQL is widely criticised for its NULL and
> > >>duplicate
> > >>treatment. There is several more little annoying inconsistencies. >>
> > >>"myth" seems a strong word to me...It's true that SQL very apparent
> > >>drawbacks consists of poor duplicates treatment and poor handling of
> > >>missing data (NULL) but I do not believe these are the worst.  Other
> > >>drawbacks appear more troubling to me into handling better relational
> > >>requirements are the fact that SQL neither correctly support domain
> > >>definition, nor it implements any real coherence of what relational
> > >>data types are.
> > >>The main impact is that a better integrity preservation, a core issue,
> > >>becomes very difficult to implement.
> > >
> > > I'm not following the above.  Bad duplicate treatment can be avoided by
> > > judicious use of primary keys and the "distinct" feature.  NULLS are
> handled
> > > pretty well by SQL,  to the extend that SQL deals with them at all.
> OTOH,
> > > some of the SQL DBMS products don't deal with missing data very well.
> > >
> > > But what really baffles me is "lack of domain definition"?  CREATE
> DOMAIN
> > > seems pretty straightforward to me...
> > > am I missing something?
> >
> > I think you are missing the part where a domain is an arbitrary data
> > type complete with its own set of operations. You seem to have confused
> > the relational domain with the rudimentary aliasing facility that
> > actually made it into SQL using a similar name.
>
> I thought the diffence between a "domain" and a "type" was precisely that
> types include operators while domains do not.

0
cimode (135)
6/1/2006 9:11:57 PM
Bob Badour wrote:

>> An application should have its SQL statements in only a few modules, and
>> all others should be SQL-free.
>> 
>> Note in my statement, you can replace SQL with GUI, XML, ORB, etc, to
>> generally the same effect. The point of modules is to isolate and
>> encapsulate.
>> 
>> Is that so hard?
> 
> Define: few

Encapsulation is hierarchical. The longer the conceptual distance between
any two points in a program, the narrower their communication should be,
if any.

So the few modules that have SQL in them should have wider communication
with each other than with others. Sometimes we call that a "Layer".

Define: wider, longer, narrower, sometimes, etc. Answer: When you don't
mix SQL in with your GUI, XML, ORB, and other what-not modules.

The alternative is like Visual Basic kiddie-kode, with multiple rampant
SQL statements inside every button event handler. That's bad, so don't do
that!

Define: bad

:-(

-- 
  Phlip
0
phlip20052 (146)
6/1/2006 9:15:20 PM
Dmitry A. Kazakov wrote:
> On 1 Jun 2006 13:07:49 -0700, Mikito Harakiri wrote:
>
> > Dmitry A. Kazakov wrote:
> >> Operations on functions (subprograms):
> >
> > These are easily defined in the realtional world (where we consider a
> > function as a relation)
> >
> >> 1. Mapping (call to) the tuple of arguments to the tuple of results
> >>
> >>    Map : f x x1 x  x2 x ... x xN -> y1 x y2 x ... x yN
> >
> > Calling a function f(x,y) with two arguments x=1 and y=2 is relational
> > join of three relations:
> >
> > 'z=f(x,y)' /\ `x=1` /\ `y=2`
> >
> > projected to attribute z.
>
> Where you get z for all possible x and y?

>From an index that corresponds to a function. Similar to index range
scan that brings tuples from an ordinary relation, a function index
allows to eavaluate only a portion of an (infinite) relation.

> Another problem is that this is
> untyped.

Relation attributes are typed.

> You should add some constrains on x and y.

Not just "some" constraints, but the one that says that in the relation
R(x,y,z) the attribute z is functionally dependent of x and y.

> You can do it externally, but it should be a function property.

I can express the constraint that relation R(x,y,z) is a function in
relational terms -- that is all what is needed.

> The third problem is that
> you need "=" for all things as well as literals for all things. It is a can
> of worms. Especially function literals aren't easy. What is a literal of
> sine?

Once again, a relation which is a function needs an index that would
make evaluating relational expressions containing functions practical.
Literals are not required. Whether the equality relation is needed is a
deep issue.

> >> 3. Comparison
> >>
> >>    = : f1 x f2 -> Boolean
> >
> > Comparison is the symmetric difference of the two relations. It is a
> > relation, not boolena value. Empty result means that the relations are
> > identical.
>
> This is non-constructive. Are you going to compare all inputs and outputs?
> Even if they model uncountable sets?

This is an interesting objection. While the question if the two
functions are equivalent is certainly important from relational engine
perspective (otherwise how would you do optimization?), it remains to
demonstrate that the end-user migh ask this question as well.

> >> 4. Copy (for marshaling, closures etc)
> >>
> >>    := : f -> f
> >
> > Copying is not a logical operation.
>
> It is. You should consider the computational state as an additional
> parameter:

Computational state is not logical concept.

> >> 5. Convolution
> >>
> >>    * : f1 x f2 x sum x prod x inv -> sum (prod (f(x), g(inv (x)))
> >
> > In your description I don't see how convolution is different from
> > composition.
>
> You have some free arguments and some bound arguments. Bound arguments run
> through some set.

Oh, you meant

sigma(x, f(x))

where x is bound variable and sigma is capital greek letter?
Calculating aggregate values is a set join (relational division).

> It can be specified through relations, of course.
> Anything can be.

Specifying "everything" through relations is not as easy as your
sentence might sound.

0
6/1/2006 9:41:07 PM
Sorry TYPO (my mistake)
<<Unfortunately, CREATE DOMAIN is a relational domain but a SQL
domain...>>
should read
<<Unfortunately, CREATE DOMAIN does NOT refer to a relational domain
but to a SQL domain...>>In a word CREATE DOMAIN is an empty shell on a
relational standpoint.

Cimode wrote:
> Thank you for your feedback...
>
> <<Bad duplicate treatment can be avoided by
>  judicious use of primary keys and the "distinct" feature>>
> Absolutely. However these are turnaround solutions to insure the
> integrity of data that are to implemented in applicative DBMS code when
> they should be dealt with by the DBMS.  As a result, during system life
> cycle what should be done once is often done each time a new view is
> defined which defeats the purpose of a DBMS.  A practical problem
> arising happens for instance when a developper leaves a company.  If
> this developper has participated in the design (or lack of design)
> process then this developper is probably aware of all the special
> conditions and features he should add (DISTINCT, IS NULL IS NOT NULL)
> to make count results correct.  But as soon as this developper leaves
> the company his knowledge often get lost which in most cases will make
> the next generation of count queries return false results because the
> new developper will not be necessarily aware of the conditions required
> to make results correct.  In a word the use of features such as
> distinct are already meaning a failure on a relational standpoint.  In
> the case of DISTINCT, their suggested use was made by Codd as a warning
> about that limitation.
>
> <<NULLS are handled pretty well by SQL>>
> The problem is not whether NULL values are well handled by SQL, the
> problem is that NULL values are SQL's only way of representing missing
> information and that this way is a poor one because relational
> predicate logic suporting relational model does not support on three
> valued logic on which SQL NULLS are essentially based.
>
> <<OTOH, some of the SQL DBMS products don't deal with missing data very
> well>>
> True, but I would phrase it otherwise.  I would rather say that some
> implementation are more *aware* of SQL limitations to handle missing
> data and that some implementation have a higher automation of getaounrd
> solutions/
>
> << But what really baffles me is "lack of domain definition"?  CREATE
> DOMAIN
>  seems pretty straightforward to me... am I missing something?>>
> Unfortunately, CREATE DOMAIN is a relational domain but a SQL domain
> which is not the same.  First they support only primitive data types
> (date/time where created only in SQL92).  Second, SQL domain data types
> are only derivation of primitive types.  Additionally, SQL domains do
> not allow to define user defined operators..As a proof of this
> limitation several SQL DBMS do not implement can not for instance
> define a table according using as a data type another table (and they
> can even less define operators for these tables).
>
>
>
> David Cressey wrote:
> > "Cimode" <cimode@hotmail.com> wrote in message
> > news:1149188800.056087.159770@h76g2000cwa.googlegroups.com...
> > > Thank you for your feedback...
> > >
> > > <<This is urban myth. SQL is widely criticised for its NULL and
> > > duplicate
> > > treatment. There is several more little annoying inconsistencies. >>
> > > "myth" seems a strong word to me...It's true that SQL very apparent
> > > drawbacks consists of poor duplicates treatment and poor handling of
> > > missing data (NULL) but I do not believe these are the worst.  Other
> > > drawbacks appear more troubling to me into handling better relational
> > > requirements are the fact that SQL neither correctly support domain
> > > definition, nor it implements any real coherence of what relational
> > > data types are.
> > > The main impact is that a better integrity preservation, a core issue,
> > > becomes very difficult to implement.
> > >
> >
> > I'm not following the above.  Bad duplicate treatment can be avoided by
> > judicious use of primary keys and the "distinct" feature.  NULLS are handled
> > pretty well by SQL,  to the extend that SQL deals with them at all.  OTOH,
> > some of the SQL DBMS products don't deal with missing data very well.
> >
> > But what really baffles me is "lack of domain definition"?  CREATE DOMAIN
> > seems pretty straightforward to me...
> > am I missing something?

0
cimode (135)
6/1/2006 10:17:04 PM
Marshall wrote:
> Joe Van Dyk wrote:
> 
>>Mikito Harakiri wrote:
>>
>>>Robert, you claim 35 years of application programming experience. Have
>>>you ever come across a performance problem when database is accessed
>>>via API
>>>
>>>getItemIdList
>>>getItemDetail
>>>
>>>so that a single jsp page issued a hundred SQL statements instead of a
>>>single one? Come on, this one is so common that it surfaces on every
>>>performance meeting.
>>
>>This problem is easily solved via caching.
> 
> 
> This is like saying: we have a big pile of dirt on our expensive
> Persian rug; what shall we do? That problem is easily solved
> by covering the dirt in a layer of palm fronds.
> 
> Caching certainly has its place in the set of tools used
> to solve performance problems. And its place is exactly:
> the tool of last resort. When everything else has failed,
> you cache. I don't know why it's so often the *first* thing
> that junior programmers come up with; maybe because
> it's easy to understand, and solving the actual problem
> requires some effort.
> 
> The *best* way to solve the performance problem that
> Mikito describes is to rewrite the object-at-a-time code
> into set-at-a-time code, which will necessarily perform
> much faster. Unfortunately OOPLs encourage object-
> at-a-time thinking, so it's hard for OO programmers to
> learn this lesson. I try to repeat it at every team
> meeting, which is not usually a problem because
> somewhere in every meeting someone will propose
> papering over a performance problem by caching.
> 
> 
> Marshall
> 

I think the *best* way depends on the particular issue at hand. 
However, I don't possess the mental aptitude necessary to make blanket 
statements about what's best for all web applications.

In RubyOnRails, I probably would create a instance variable in the 
Controller that contains the data from one SQL statement (perhaps 
automatically generated in the Model), and use that data in the view. 
I'm sure that's horrible and won't work.  All those applications out 
there that I've written are probably busy crashing and corrupting data, 
as I'm using objects and escapulation or something.

Joe
0
joe.vandyk (160)
6/1/2006 10:49:34 PM
Bob Badour wrote:
> This 'domain logic' to which you refer. What does it do that is not
> entering, manipulating, reporting or deriving data? Of that which
> remains, what does not interface with the external world through some
> device or another?

I'm guessing a little here, but I reckon we're going to run into the
"Business Logic Layer" here. You know, the one between the "User
Interface Layer" and the "Persistence Layer".

Warning. Rant follows.

<rant>
I used to think it was me. I really couldn't figure out what I was
missing with OO. What was the big deal, compared to abstract data types
allied to modular programming ? I'm finally coming to the conclusion
that the reason I couldn't figure out what I was missing is perhaps
because *there's nothing to miss*. OO seems to be a complexity mill to
take even the simplest requirement and turn it into a monster, and
worse, a myopic monster that fails to take into account other world
views than the "object model" the designer came up with that day, a
monster with APIs here, layers there, an ORM lurking in the corner,
maybe even an ORB hanging around somewhere, value objects for
this'n'that, and hey, we need a configuration file so in lumbers XML,
and all of this just to manage assignment statements nicer. Oh, and God
help us if we ever have concurrent access to a non-synchronised
variable.

And underneath all of this, what ? A formal model ? Anything we can
reason about in strict, precise mathematical terms ? Don't be daft. OO
is all about experimentation, throwing things at the wall to see what
sticks ! I was struck in an earlier sub-thread by the difference
between what some consider "object oriented" languages and "class
oriented" languages. It reminded me fleetingly of the banter we have on
c.d.t. - "Oracle isn't a relational database, it's an SQL database !"
"Java isn't an object oriented language, it's a class oriented language
!" The difference, the big difference, the huge difference that makes
all the difference in the world, is that we have a formal, precise
reason for our arguments - the OO community just have a pile of fuzzy
lumps of contradicting prose, with no real hope of a formal, precise
statement of principle or intent. Look at the work that's gone into the
relational model over the last 30+ years - it's taken some missteps,
things have been added - but the real trajectory of thinking in RM is
to clarify and if anything prune back and remove supposed restrictions
to a precise, simple (but not trivial), clear view on what the RM is
and what it means. What hope for OO in following any similar path ?
None, so far as I can see - even with "aspect oriented programming"
looming into view.

I admit, it was embarrassing in the '90s to still admit that the
majority of the world's code was in COBOL. But did we really have to
try changing that ratio by generating mountains of boilerplate Java
junk for even the simplest of applications ?
</rant>

Ok, so I exaggerate. There's a bit of hyperbole in there. It was a bit
of a vent. You know, I'd love the scales to fall from my eyes, to see
the bright new future in OO programming. Enough people I know whose
opinions I generally hold in some regard seem to look kindly on it. But
I just can't get past that, as currently constituted, it all still
revolves around managing variables and assignments. We don't need that
stuff anymore. Not at the level of abstraction we should be working at.
Leave the bits'n'bytes to the OS engineers, the DBMS engineers and
their ilk. Let's get on with the "what", and leave them to the "how".

0
6/1/2006 10:49:52 PM
phlip wrote:

> Bob Badour wrote:
> 
> 
>>>An application should have its SQL statements in only a few modules, and
>>>all others should be SQL-free.
>>>
>>>Note in my statement, you can replace SQL with GUI, XML, ORB, etc, to
>>>generally the same effect. The point of modules is to isolate and
>>>encapsulate.
>>>
>>>Is that so hard?
>>
>>Define: few
> 
> 
> Encapsulation is hierarchical. The longer the conceptual distance between
> any two points in a program, the narrower their communication should be,
> if any.
> 
> So the few modules that have SQL in them should have wider communication
> with each other than with others. Sometimes we call that a "Layer".

Define few
0
bbadour (434)
6/1/2006 10:55:14 PM
On 2006-05-31 13:03:21 -0500, "Marshall" <marshall.spight@gmail.com> said:

> A common misconception among application programmers
> is that their technique of managing integrity with hand written
> code protected by object encapsulation is the equal of
> a centrally managed declarative integrity constraint, and
> that it's merely six of one, half dozen of the other.

Can you cite a source for this other than your own opinion?

> In fact, the reality is that the declarative integrity constraint
> is at a higher level of abstraction, and is at a much lower
> cost to produce and maintain, and at a much lower risk
> for error, than the hand-written code.

I quite agree that a DBMS provides a certain level of security and 
integrity at a reasonable cost.  That security is not perfect, and the 
integrity can be corrupted given sufficient effort and knowledge (or 
carelessness); but it remains true.

However, the data cannot remain in the DBMS for its entire lifetime.  
The RNA has to leave the nucleus and get out into the cytolasm to do 
it's work.  And out there in the cytoplasm the integrity of the data is 
no longer the responsibility of the DBMS.

So applications have an equal responsibility to maintain the integrity 
and security of the data while they control that data.

But this is a side issue.  The issue that started this feeding frenzy 
of self-contratulatory ad-hominem arguments was the notion that the 
design of application programs should be so strongly decoupled from the 
DBMS as to afford the replacement of the DBMS with a completely 
different technology.

-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/1/2006 11:03:39 PM
On 2006-05-31 13:32:44 -0500, Bob Badour <bbadour@pei.sympatico.ca> said:

> Most of what he [Martin] refers to as application code simply derives 
> new statements from the data, which is what a logic predicate would do.

Perhaps you could clarify that statement.  In other words... HUH?


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/1/2006 11:04:08 PM
On 2006-05-31 13:14:41 -0500, "David Cressey" <dcressey@verizon.net> said:

> I think the validity of your point of view depends on whether you view the
> database as belonging to a single application,
> or whether multiple applications,  perhaps originally provided  by different
> vendors,  collaborate with each other by using the same database to store
> persistent data.
> 
> Most people who have worked in application development workshops assure me
> that such a scenario is unheard of. on the other hand,  I assure you that,
> when the ideas about enterprise databases were being developed in the 1960s
> and 1970s,  this was at the heart of what a database was all about.  The
> idea of embedding a "data bank"  (if you prefer that terminology) in a
> single application would have struck them as quaint, bordering on absurd.

Of course we see both kinds.  We see huge applications like MSWord, 
MSProject, or, in fact, most of the office suite which completely embed 
the data bank within themselves.  (Sans things like OLE and it's 
derivatives).  We also see huge enterprise systems of many 
collaborating applications using a single huge enterprise data model.  
And, we see lots of system in between.

However, none of this validates the notion that the DB is the bricks 
and the applications are the mortar.  Indeed that metaphor is just 
silly.  Bricks and mortar build static structures.  Systems are dynamic 
structures.
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/1/2006 11:09:14 PM
Marshall wrote:
> Christian Brunschen wrote:
> 
>>For a trivial example, consider an application that needs to somehow
>>authenticate users (because different users have permission or not for
>>different parts of the functonality of the application. The user
>>information (name, password, etc) will have to be stored somewhere - a
>>relational database might be an excellent place, in particular if this
>>application is essentially a stand-alone one.
>>
>>However, it might be that the application is intented to be integrated
>>into an existing infrastructure, that has user information stored in an
>>LDAP-accessible database; or for another example, the user information
>>might be stored in a Unix-style flat file (a la /etc/passwd).
>>
>>By separating out the logic that handles any interaction between the
>>chosen database into separate, database-specific modules that share a
>>common interface, the rest of the application can remain identically the
>>same, with only the database-specific parts needing to be plugged in or
>>out, depending on the precise environment where the application is
>>deployed.
> 
> 
> There's a severe problem with that logic, though.
> 
> If you want to build a layer to wrap a variety of different storage
> mechanisms, that layer *cannot* be any more powerful than
> the weakest mechanism you want to layer on top of. Which
> means your very high level, very powerful SQL dbms will
> be stuck at the level of the stupidest file store ever invented.

Unless one wants to re-implement larges parts of a dbms, as you have 
pointed out several times.


> And in swoops the application programmer to "save" the day
> from the problem he invented! All he has to do is write that
> subset of a DBMS that he needs today. Which will slowly,
> over time, increase until it's a badly implemented, bug ridden,
> ad hoc implementation of half of a database. This is
> Spight's Law. You have to have a dbms, whether you
> use a good one or reinvent it yourself, badly.

Man, you sure are pushing hard for a legacy. Do you not intend to number 
your laws? Should we take that as Spight's First Law? Or Spight's Zeroth 
Law? And law of what?

Are we allowed to paraphrase? Like, for instance, would you accept 
someone reworking it to: "Spight's Law: Necessity is the mother of 
re-invention." ?


> To put it in the terms of application programming, it is as if
> we decided we want to be able to swap our programming
> language one for another at will. So we can't use any features
> of any programming language that isn't in all of them.
> Oh, and we want assembly to be on the list.
> 
> Marshall
> 
> PS. Props to Greenspun's Tenth.

You and your obscure references to interesting geeks. You caused me to 
waste an entire afternoon reading various and sundry snippets from 
Greenspun's sites.
0
bbadour (434)
6/1/2006 11:14:04 PM
phlip wrote:
> Mikito Harakiri wrote:
>
> > Assertion alone is worthless without solid method that supports it.
>
> Be prepared to respond with whatever solid method you used to support your
> own current technique. ;-)
>
> > And
> > what method OO propellerheads suggest? OR mappers (which essentially
> > are reincarnated OODBMS)? What I am supposed to learn 20 something
> > ad-hock mapping types instead of 6 clean relational operators? Or worse
> > yet, some "pattern"?
>
> An application should have its SQL statements in only a few modules, and
> all others should be SQL-free.

Why? The SQL statements should be included into those modules that
query/modify information from database. Would it be a few or many
entirely depends on the application functionality.

> Note in my statement, you can replace SQL with GUI, XML, ORB, etc, to
> generally the same effect. The point of modules is to isolate and
> encapsulate.

I don't challenge your goal, but relational model abstractions are too
sophisticated to give up to such primitive methods. Striving to make
your application database agnostic results in the flaws which expose
designers data management ignorance.

0
6/1/2006 11:18:35 PM
Christian Brunschen wrote:
> In article <lsBfg.3076$%86.209@trndny04>,
> David Cressey <dcressey@verizon.net> wrote:
> 
>>"Christian Brunschen" <cb@festis.df.lth.se> wrote in message
>>news:e5mir9$gug$1@news.lth.se...
>>
>>>For a trivial example, consider an application that needs to somehow
>>>authenticate users [ ... ]
>>
>>What makes the example trivial?  Do you mean trivial in the sense that
>>mathematicians use the word, in the sense that engineers use the word,  or
>>in the sense that common parlance uses the word?
> 
> In a very loose common parlance sense of the example being easy to come up 
> with, not being contrived and thus something that people do occasionally 
> encounter.

You left out the part where it was not very illuminating either. 
Assuming one decides that forgoing the authentication system built into 
every dbms is a good idea in the first place, authentication lends 
itself to a simple predicate (using the computer programming definition) 
or similarly simple subroutine regardless.

Your argument is as valid as stating one should create a square root 
function to isolate the program from numerical methods or a distance 
function to isolate the program from your choice of square root function.

While I consider the separation of concerns a sound design principle, 
your argument leaves me uncertain as to what concerns you intend to 
separate.
0
bbadour (434)
6/1/2006 11:26:20 PM
Christian Brunschen wrote:

> In article <1149165601.331313.237840@u72g2000cwu.googlegroups.com>,
>  <frebe73@gmail.com> wrote:
> 
>>>For a trivial example, consider an application that needs to somehow
>>>authenticate users (because different users have permission or not for
>>>different parts of the functonality of the application. The user
>>>information (name, password, etc) will have to be stored somewhere - a
>>>relational database might be an excellent place, in particular if this
>>>application is essentially a stand-alone one.
>>>
>>>However, it might be that the application is intented to be integrated
>>>into an existing infrastructure, that has user information stored in an
>>>LDAP-accessible database; or for another example, the user information
>>>might be stored in a Unix-style flat file (a la /etc/passwd).
>>
>>Yes, authentication data may be stored in older obsolete hierachial
>>databases (LDAP). 
> 
> 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.


>>Using a pluggable solution is a good strategy here,
>>like JAAS if you are using Java. But I have never seen any
>>authentication solution were you actually get username and password
> 
>>from the store. Instead you ask a serverice if your username/password
> 
>>pair is correct or not. In this case, the interface sould not be
>>between the application and the database, but between the application
>>and a pluggable service.
> 
> 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.

[snip]


>>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.

[snip]


>>Actually it would also be possible to write an own ODBC driver catching
>>the SQL statements accesing the "user" table and call the LDAP database
>>instead. 
> 
> 
> ... 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? 
Do you likewise recommend implementing higher-level interfaces to your 
C/C++/Java/OO-du-jour in assembler?


  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? 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?

[snip]


>>(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" ? Does "cool" justify the expense? Are you the 
one actually paying for "cool" or is that someone else?
0
bbadour (434)
6/1/2006 11:39:23 PM
Joe Van Dyk wrote:

> Marshall wrote:
> 
>> Joe Van Dyk wrote:
>>
>>> Mikito Harakiri wrote:
>>>
>>>> Robert, you claim 35 years of application programming experience. Have
>>>> you ever come across a performance problem when database is accessed
>>>> via API
>>>>
>>>> getItemIdList
>>>> getItemDetail
>>>>
>>>> so that a single jsp page issued a hundred SQL statements instead of a
>>>> single one? Come on, this one is so common that it surfaces on every
>>>> performance meeting.
>>>
>>> This problem is easily solved via caching.
>>
>> This is like saying: we have a big pile of dirt on our expensive
>> Persian rug; what shall we do? That problem is easily solved
>> by covering the dirt in a layer of palm fronds.
>>
>> Caching certainly has its place in the set of tools used
>> to solve performance problems. And its place is exactly:
>> the tool of last resort. When everything else has failed,
>> you cache. I don't know why it's so often the *first* thing
>> that junior programmers come up with; maybe because
>> it's easy to understand, and solving the actual problem
>> requires some effort.
>>
>> The *best* way to solve the performance problem that
>> Mikito describes is to rewrite the object-at-a-time code
>> into set-at-a-time code, which will necessarily perform
>> much faster. Unfortunately OOPLs encourage object-
>> at-a-time thinking, so it's hard for OO programmers to
>> learn this lesson. I try to repeat it at every team
>> meeting, which is not usually a problem because
>> somewhere in every meeting someone will propose
>> papering over a performance problem by caching.
>>
>> Marshall
> 
> I think the *best* way depends on the particular issue at hand. However, 
> I don't possess the mental aptitude necessary to make blanket statements 
> about what's best for all web applications.
> 
> In RubyOnRails, I probably would create a instance variable in the 
> Controller that contains the data from one SQL statement (perhaps 
> automatically generated in the Model), and use that data in the view. 
> I'm sure that's horrible and won't work.  All those applications out 
> there that I've written are probably busy crashing and corrupting data, 
> as I'm using objects and escapulation or something.

False dichotomy is fallacious reasoning. If your programs crash, I 
suggest it has more to do with the way you reason than what tool you used.
0
bbadour (434)
6/1/2006 11:45:35 PM
Joe Van Dyk wrote:
> Marshall wrote:
> > Joe Van Dyk wrote:
> >>Mikito Harakiri wrote:
> >>
> >>>Robert, you claim 35 years of application programming experience. Have
> >>>you ever come across a performance problem when database is accessed
> >>>via API
> >>>
> >>>getItemIdList
> >>>getItemDetail
> >>>
> >>>so that a single jsp page issued a hundred SQL statements instead of a
> >>>single one? Come on, this one is so common that it surfaces on every
> >>>performance meeting.
> >>
> >>This problem is easily solved via caching.
> >
> >
> > This is like saying: we have a big pile of dirt on our expensive
> > Persian rug; what shall we do? That problem is easily solved
> > by covering the dirt in a layer of palm fronds.
> >
> > Caching certainly has its place in the set of tools used
> > to solve performance problems. And its place is exactly:
> > the tool of last resort. When everything else has failed,
> > you cache. I don't know why it's so often the *first* thing
> > that junior programmers come up with; maybe because
> > it's easy to understand, and solving the actual problem
> > requires some effort.
> >
> > The *best* way to solve the performance problem that
> > Mikito describes is to rewrite the object-at-a-time code
> > into set-at-a-time code, which will necessarily perform
> > much faster. Unfortunately OOPLs encourage object-
> > at-a-time thinking, so it's hard for OO programmers to
> > learn this lesson. I try to repeat it at every team
> > meeting, which is not usually a problem because
> > somewhere in every meeting someone will propose
> > papering over a performance problem by caching.
> >
>
> I think the *best* way depends on the particular issue at hand.
> However, I don't possess the mental aptitude necessary to make blanket
> statements about what's best for all web applications.

You misunderstand. I was only referring to the specific
class of problem that Mikito mentioned.


> In RubyOnRails, I probably would create a instance variable in the
> Controller that contains the data from one SQL statement (perhaps
> automatically generated in the Model), and use that data in the view.
> I'm sure that's horrible and won't work.

To the extent that I understood what you said, it sounds like
you are saying you'd do the specific thing that I was proposing
as a solution. So I don't see where we have any disagreement.


> All those applications out
> there that I've written are probably busy crashing and corrupting data,
> as I'm using objects and escapulation or something.

It is entirely possible to write useful apps in OOPLs that access
databases. It's what I do for a living.

There are good ways and bad ways to go about it, of course ....


Marshall

0
6/1/2006 11:47:33 PM
Dmitry A. Kazakov a �crit :
> On Thu, 01 Jun 2006 02:50:54 +0200, Bruno Desthuilliers wrote:
> 
> 
>>I'm afraid your confusing OO (ie: *object* oriented) with 
>>"class-oriented" (like in Java). In a "true OO language", *everything* 
>>is an object. So functions are objects too. So functions are first-order.
> 
> 
> I don't think it could be consistent to have everything an object. 

Why so ?

0
6/1/2006 11:48:43 PM
Mikito Harakiri wrote:

> I don't challenge your goal, but relational model abstractions are too
> sophisticated to give up to such primitive methods. Striving to make
> your application database agnostic results in the flaws which expose
> designers data management ignorance.

I didn't say to make the database agnostic. That would be an interface as 
wide as the database itself. I implied to give the application narrow 
interfaces. An application-specific interface can indulge in conveniences, 
such as declining to accept most of the different datatypes that 
professional DBs accept. Simple applications would need int, currency, and 
string, for example.

So generic, 3rd party systems like databases have wide interfaces, and 
modules within a program have narrow ones. And the source code to a big DB 
must follow this rule, too!

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!


0
phlipcpp (2771)
6/2/2006 1:31:01 AM
Bob Badour wrote:

> Define few

Application-specific.

(And pretending not to understand a post is a very tired USENET cheap 
trick...)

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!


0
phlipcpp (2771)
6/2/2006 1:32:08 AM
Phlip wrote:

> Bob Badour wrote:
> 
>>Define few
> 
> Application-specific.
> 
> (And pretending not to understand a post is a very tired USENET cheap 
> trick...)

That's not a definition. So basically, what you wrote is entirely 
meaningless. Pretending to understand meaningless gibberish is just stupid.
0
bbadour (434)
6/2/2006 1:43:38 AM
Bob Badour wrote:

> That's not a definition. So basically, what you wrote is entirely 
> meaningless. Pretending to understand meaningless gibberish is just 
> stupid.

Bye-bye. ;-)


0
phlipcpp (2771)
6/2/2006 1:53:33 AM
[...]
>The third problem is that
> you need "=" for all things as well as literals for all things. It is a can
> of worms.

Why is it 'a can  of worms'?

> Especially function literals aren't easy. What is a literal of
> sine?

You tell us 'what is a literal of sine'.  There is no such creature in
math.


> Even if they model uncountable sets?

Interesting to know how would you go about 'model[ing] uncountable
sets' in your OO tool of choice.


>. In general, when you want to enforce some
> semantics on the resulting function.

What kind of semantics do you have in mind ? Any computer program can
be regarded as having say denotational semantics.  Is that what you
have in mind ? If so,  you do not need to 'enforce' anything -- as soon
as you've written your program the semantics is already there.

> >> Because in this particular case function is a value and values are outside
> >> the language scope.

That does not make any obvious sense -- how a function can be a value
that is outside the language scope ?  Surely it depends on the language
in question.


> Right. The problem is that mathematical constructs modeled in a
> computational framework might be too large for any finite state machine. So
> an uncountable set of real numbers is replaced by a finite set of
> intervals.

What do you mean by 'a finite set of  intervals' ?  If you mean the
floating point arithmetic, then the numerals in this arithmentic
nominally represent members of a finite subset of rational numbers with
peculiar operations (+, -, *, /) that are affected by rounding issues.

>That's the gibberish in which I am talking. We can't have all
> the table of real-valued functions.

You do not need one.  It's well-known that sine is a Turing-computable
function.  Otherwise,  how would a gadget like your PC produce it ?


> The size of this table is aleph-2!

It is not.


> Where you find a hard disk of this size? Fortunately, from all this table,
> today, I need only sine. So I say let sine be denoted as 0x2.

You are not making much sense here.

>
> Nevertheless, nothing prevents us to formalize these bastards and use
> mathematical rigour to handle them.

What 'bastards' do you intend to formalize ?  Could you,  like,
demonstrate ?

Disagree?
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

0
boston103 (240)
6/2/2006 2:01:10 AM
Phlip wrote:

> Bob Badour wrote:
> 
>>That's not a definition. So basically, what you wrote is entirely 
>>meaningless. Pretending to understand meaningless gibberish is just 
>>stupid.
> 
> Bye-bye. ;-)

Bye! For other readers who might have a clue or who might want to get 
one, I direct folks to EWD 898:

"The major attraction of the modern elixirs is that they relieve their 
consumers from the obligation of being precise by presenting an 
interface too fuzzy to be precise in: by suppressing the symptoms of 
impotence they create an illusion of power."

http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD898.html

I am convinced that most OO proponents have been dipping heavily into 
the purple koolaid. They almost universally predicate everything they 
say or do on meaningless nonsense.
0
bbadour (434)
6/2/2006 2:06:37 AM
On 2006-05-31 13:44:06 -0500, "Tony D" <tonyisyourpal@netscape.net> said:

> Others have debunked a variety of areas in this post already but a few
> bits caught my eye ...
> 
> Robert Martin wrote:
>> This statement is fascinating.  It takes the view that the majority of
>> the system is DB and that application code simply fills the cracks.
>> The DB represents the bricks and the application code is the mortar.
>> 
> 
> Applications come and go. Languages come and go. Character interfaces
> came and went. Client-server came and kind of went. Batch applications
> made a bit of a come-back in nice new clothes as web apps. And guess
> what ? The database is still there. Where would that suggest we expend
> our efforts ?

On the domain that is changing, since that's where the "progress" is 
being made.  I presume that you are glad that character interfaces were 
replaced.

The point is that the majority of our effort is NOT spent on the 
database because the database does not do the majority of what needs to 
be done.

>> ...  Frankly, it IS the responsibility of the application to enforce 
>> integrity.  Oh, the
>> DB can enforce it while the data is in the warehouse, but the data
>> comes out of the warehouse, gets transported all over the place, gets
>> transformed in many different ways into many different products, gets
>> presented to many different customers and put into many different
>> systems, and for all these activities it is the APPLICATION that must
>> enforce the integrity of the data.  The DB loses control once the data
>> is out of the warehouse.
>> 
> 
> Oh fabbo ! Let's take the data, throw it around a network a bit for
> processing, then throw it back around the network for storing it again
> ! Network bandwidth vendors must be rubbing their hands with glee at
> this sort of thinking.

Did I use the term "Network"?  I was referring to the movement and 
transformation of data in a system.  That system might be distributed, 
or wholly contained within a single processor.

> The biggest performance black hole in a
> networked application isn't the database, or the transaction log, or
> the PC client, or the disk drives - it's that gnarly chunk of wire
> running from the server to who knows where to wherever the client code
> is, and back again. The more goes through that chunk of wire, the
> slower things go. Better to leave the data exactly where it is for as
> much of the time as possible.

I quite agree.  Which is one reason that I question the ubiquitous use 
of database servers.  Not that they aren't useful; of course they are.  
It's just that few people seem to question whether or not they should 
be used on a case by case basis.

But I don't know how we got on this topic, since the topic of the 
original post was a question of application design structure.  Towit: 
Do you agree that the design of an application program should be 
strongly decoupled from the DBMS, to the extent that the DBMS could be 
swaped out for a completely different technology.

> Incidentally, how do you write batch applications ? You know, those
> apps that deal with *lots* of data in one go ? Or do we only think
> about interactive, or pseudo-interactive, applications nowadays ?

FOREVER {
  READ
  PROCESS
  WRITE
}

>> Clearly keeping the integrity of the data in the warehouse is
>> important.  But that's not the whole story.  It's not even most of the
>> story.
>> 
>> Finally, and this is critical to the understaning of my point, the code
>> in which data integrity is specified IS application code.  It may be
>> written in a special purpose DB language, or it may not.  But it is
>> code that supports the application.
>> 
> 
> Integrity *must* be managed in the database.

Agreed.  But when the data is moving around the system, it is the 
application that keeps it intact.

> That way, any and every
> application that uses that data gets a consistent view.

Agreed.  However, the applications must keep the data sane as they 
manipulate it.

> Not just "the"
> or "a" application - all of them.

Agreed.

> Including your shiny bespoke coded
> application but also the GUI report writer, the Excel spreadsheet with
> the ODBC link, the SQL terminal monitor session, and all the other
> routes to seeing the data application programmers have a wee tendency
> to forget about.

Agreed.  Believe me.  Agreed.  I have a team at the moment that is 
replacing a suite of applications that were written by unskilled people 
in a hurry, and that caused terrible problems of database corruption 
that had to be manually repaired on a daily basis.  So I know.

> "Why are we seeing strange outputs on the reports ?"
> "It seems someone updated some data without going through the
> application, so we couldn't make sure they stuck to the rules."
> "!!!"

In our case, of course, the corruption took place WITHIN the 
applications.  The database (Oracle) simply accumluated more and more 
cruft.

> Always remember kiddies - it's a bit like puppies.
> "Databases are for life - applications are for Christmas."

Cute.  Christmas seems to be coming very frequently nowadays, and boy 
do we pay a lot for those presents!

> So far as I'm concerned, the best applications I've seen have put all
> the integrity, constraints, and heavy business logic in the database.
> The front end took care of basic validation of input and organising
> workflow. (And even then, because the front ends were in Java and the
> file format "chosen" was XML, there seemed to be a lot of, from the
> outside, unnecessary pushing and shoving going on out there.) But never
> mind - we can replace the front end with .Net, or whatever comes next -
> the important bits stay the same, tucked away in the database,
> oblivious to the fads and fashions outside.

Yeah, that's how he wrote it.  A shame too.  I'm sure you could have 
done better.  But we've redone it using .Net.  Of course we've 
maintained a lot of the integrity checks in the DB.  But we've moved a 
lot of the business rules into the C# code so that we can test with 
automated unit tests.

-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/2/2006 2:25:20 AM
Alfredo Novoa wrote:
> Robert Martin wrote:

<snip>

Question for the "the system's behavior needs to be in the dbms" people:

My current view of a dbms is that it's a place to store stuff. 
Obviously, it can be much more than that.

Say I'm writing an e-commerce website.  I'm restricted to cheap and/or 
free databases, but feel free to assume that I'm not.

The credit card supplied with the order needs to be verified against an 
external encrypted web service.  If the order goes through, then it 
needs to notify another web service that fulfills the order.  Once UPS 
ships, I need to get that information from UPS.  If all the rules for 
the sytem are in the dmbs, can the dbms do all that external stuff? 
Perhaps through stored procs?

If so, is anyone aware of any open source web applications that do have 
all the rules for the system in the database?

And to you same people, do you think there's room for "application 
databases", where applications (who may or may not use databases for 
storing information) talk to each other through well-defined interfaces?

Thanks,
Joe
0
joe.vandyk (160)
6/2/2006 2:52:19 AM
vc wrote:

> [...]
> 
>>The third problem is that
>>you need "=" for all things as well as literals for all things. It is a can
>>of worms.
> 
> Why is it 'a can  of worms'?

The problems regarding equality and literals apply equally when one 
treats functions as object instances as when one treats them as 
relations so Dmitry basically hoists himself on his own petard.

Equality poses some problems. For instance cos(x-pi/2) = sin(x)

Unless I recall incorrectly, something I read recently about Church and 
the lambda calculus suggests that evaluating the equality of two 
arbitrary functions is undecidable.

If one assumes cos and sin are defined on an infinite range, which is 
impossible to implement on a finite computer, then it would take 
infinite resources to verify the equality above. If one assumes cos and 
sin are defined on the same large finite range, the computer will treat 
the above as unequal due to fact that (x-pi/2) is defined for more 
values at the negative end of the range than is x and for fewer values 
at the positive end of the range than is x.

ie. if the range of x is [MIN_X,MAX_X], then the range of (x-pi/2) is 
[MIN_X-pi/2,MAX_X-pi/2]


>>Especially function literals aren't easy. What is a literal of
>>sine?
> 
> You tell us 'what is a literal of sine'.  There is no such creature in
> math.

I gave two above, which I repeat here:

sin(x)
cos(x-pi/2)

Actually, there are potentially several in math depending on whether 
'literal' means 1) a terminal symbol in a formal grammar, 2) a notation 
for representing a value, or 3) an elementary proposition or its 
negation in logic. One can subsume all three uses under the broad field 
of mathematics.

http://en.wikipedia.org/wiki/Literal


>>Even if they model uncountable sets?
> 
> Interesting to know how would you go about 'model[ing] uncountable
> sets' in your OO tool of choice.

One might name an uncountable set with some symbol and write expressions 
using that symbol. However, no finite computer can evaluate all of the 
elements of such a set.

Once again, that applies equally to functions as object instances as to 
anything else.


>>. In general, when you want to enforce some
>>semantics on the resulting function.
> 
> What kind of semantics do you have in mind ? Any computer program can
> be regarded as having say denotational semantics.  Is that what you
> have in mind ? If so,  you do not need to 'enforce' anything -- as soon
> as you've written your program the semantics is already there.

Good question. Perhaps he meant something along the lines of Hoare Logic 
with pre- and post- conditions? Or does that even matter as much as 
things like distributivity, transitivity, commutativity, associativity 
etc. which are not semantics really; although, they are properties one 
can derive from the semantics of functions?


>>>>Because in this particular case function is a value and values are outside
>>>>the language scope.
> 
> That does not make any obvious sense -- how a function can be a value
> that is outside the language scope ?  Surely it depends on the language
> in question.
> 
>>Right. The problem is that mathematical constructs modeled in a
>>computational framework might be too large for any finite state machine. So
>>an uncountable set of real numbers is replaced by a finite set of
>>intervals.
> 
> What do you mean by 'a finite set of  intervals' ?  If you mean the
> floating point arithmetic, then the numerals in this arithmentic
> nominally represent members of a finite subset of rational numbers with
> peculiar operations (+, -, *, /) that are affected by rounding issues.

You answered your own question. If two real numbers or unrepresentable 
rational numbers round to the same representable rational, then the 
computer will consider them equal. Thus, each representable rational 
represents an interval of reals or of rationals that will round to it.


>>That's the gibberish in which I am talking. We can't have all
>>the table of real-valued functions.
> 
> You do not need one.  It's well-known that sine is a Turing-computable
> function.  Otherwise,  how would a gadget like your PC produce it ?
> 
>>The size of this table is aleph-2!
> 
> It is not.

It makes for a better straw man if it is, though.


>>Where you find a hard disk of this size? Fortunately, from all this table,
>>today, I need only sine. So I say let sine be denoted as 0x2.
> 
> You are not making much sense here.

He makes sense. He is attacking a straw man he constructed. It's 
pointless and unpersuasive, but it is easy enough to see what he is up to.


>>Nevertheless, nothing prevents us to formalize these bastards and use
>>mathematical rigour to handle them.
> 
> What 'bastards' do you intend to formalize ?  Could you,  like,
> demonstrate ?
> 
> Disagree?
0
bbadour (434)
6/2/2006 2:54:01 AM
Joe Van Dyk wrote:
> Alfredo Novoa wrote:
> 
>> Robert Martin wrote:
> 
> 
> <snip>
> 
> Question for the "the system's behavior needs to be in the dbms" people:
> 
> My current view of a dbms is that it's a place to store stuff. 
> Obviously, it can be much more than that.
> 
> Say I'm writing an e-commerce website.  I'm restricted to cheap and/or 
> free databases, but feel free to assume that I'm not.
> 
> The credit card supplied with the order needs to be verified against an 
> external encrypted web service.  If the order goes through, then it 
> needs to notify another web service that fulfills the order.  Once UPS 
> ships, I need to get that information from UPS.  If all the rules for 
> the sytem are in the dmbs, can the dbms do all that external stuff? 
> Perhaps through stored procs?
> 
> If so, is anyone aware of any open source web applications that do have 
> all the rules for the system in the database?
> 
> And to you same people, do you think there's room for "application 
> databases", where applications (who may or may not use databases for 
> storing information) talk to each other through well-defined interfaces?
> 
> Thanks,
> Joe

Doing some research, and it looks like it's quite possible.  From 
Oracle, at least.  Interesting.

http://www.oracle.com/technology/sample_code/tech/java/jsp/samples/wsclient/Readme.html

0
joe.vandyk (160)
6/2/2006 3:07:31 AM
Joe Van Dyk wrote:

> Alfredo Novoa wrote:
> 
>> Robert Martin wrote:
> 
> <snip>
> 
> Question for the "the system's behavior needs to be in the dbms" people:
> 
> My current view of a dbms is that it's a place to store stuff. 
> Obviously, it can be much more than that.
> 
> Say I'm writing an e-commerce website.  I'm restricted to cheap and/or 
> free databases, but feel free to assume that I'm not.
> 
> The credit card supplied with the order needs to be verified against an 
> external encrypted web service.  If the order goes through, then it 
> needs to notify another web service that fulfills the order.  Once UPS 
> ships, I need to get that information from UPS.  If all the rules for 
> the sytem are in the dmbs, can the dbms do all that external stuff? 
> Perhaps through stored procs?
> 
> If so, is anyone aware of any open source web applications that do have 
> all the rules for the system in the database?
> 
> And to you same people, do you think there's room for "application 
> databases", where applications (who may or may not use databases for 
> storing information) talk to each other through well-defined interfaces?

This gets back to some questions I asked elsewhere in this massive thread:

"This 'domain logic' to which you [Sasa] refer. What does it do that is 
not entering, manipulating, reporting or deriving data? Of that which 
remains, what does not interface with the external world through some 
device or another?"

Obviously, the primary domain of data management systems includes 
entering, manipulating, reporting and deriving data. The best formalism 
we currently have for doing all of that is the relational model.

The questions that remain are: How often does the relational model 
provide a good formalism for interfacing with the external world? Do we 
have better formalisms for interfacing with the external world? How can 
we improve upon the formalisms we have?

Certainly, at the logical level, we could use relations instead of SOAP 
requests and responses to communicate to external systems, and at the 
logical level, we could treat those external systems as sets of relation 
variables. At the physical level, we could even use SOAP requests and 
responses to represent the relations.

Doing so would mean we would have all the features available for making 
views updatable at our disposal for dealing with versioning issues.

Doing so would mean we would have the full power of the calculus for 
expressing constraints.

Doing so would make issuing a set of requests as easy as issuing a 
single request.

Doint so would leverage the existing encryption, 
authentication/security, transaction, auditing, integrity etc. functions 
of the dbms.

I have no doubt that Dr. Codd expected businesses to use relations for 
communicating. Of course, businesses must still find some common ground 
for doing so.

I suggest it is possible to create a 'driver' that represents any 
physical I/O device as relation variables. Whether that is always the 
best thing to do is a good question to ask even if we do not have the 
answer. Even if we suspect the answer is "no", the question then becomes 
"When is it the best thing to do?"

Again, doing so would leverage existing encryption, 
authentication/security, transacton, auditing, integrity etc. functions 
of the dbms.
0
bbadour (434)
6/2/2006 4:02:02 AM
Joe Van Dyk wrote:

> Joe Van Dyk wrote:
> 
>> Alfredo Novoa wrote:
>>
>>> Robert Martin wrote:
>>
>> <snip>
>>
>> Question for the "the system's behavior needs to be in the dbms" people:
>>
>> My current view of a dbms is that it's a place to store stuff. 
>> Obviously, it can be much more than that.
>>
>> Say I'm writing an e-commerce website.  I'm restricted to cheap and/or 
>> free databases, but feel free to assume that I'm not.
>>
>> The credit card supplied with the order needs to be verified against 
>> an external encrypted web service.  If the order goes through, then it 
>> needs to notify another web service that fulfills the order.  Once UPS 
>> ships, I need to get that information from UPS.  If all the rules for 
>> the sytem are in the dmbs, can the dbms do all that external stuff? 
>> Perhaps through stored procs?
>>
>> If so, is anyone aware of any open source web applications that do 
>> have all the rules for the system in the database?
>>
>> And to you same people, do you think there's room for "application 
>> databases", where applications (who may or may not use databases for 
>> storing information) talk to each other through well-defined interfaces?
>>
>> Thanks,
>> Joe
> 
> Doing some research, and it looks like it's quite possible.  From 
> Oracle, at least.  Interesting.
> 
> http://www.oracle.com/technology/sample_code/tech/java/jsp/samples/wsclient/Readme.html 

Their solution is too low-level, if you ask me. But it has the advantage 
that one can do it today using an existing dbms.
0
bbadour (434)
6/2/2006 4:14:44 AM
Joe Van Dyk wrote:
> Joe Van Dyk wrote:
> 
>> Alfredo Novoa wrote:
>>
>>> Robert Martin wrote:
>>
>>
>>
>> <snip>
>>
>> Question for the "the system's behavior needs to be in the dbms" people:
>>
>> My current view of a dbms is that it's a place to store stuff. 
>> Obviously, it can be much more than that.
>>
>> Say I'm writing an e-commerce website.  I'm restricted to cheap and/or 
>> free databases, but feel free to assume that I'm not.
>>
>> The credit card supplied with the order needs to be verified against 
>> an external encrypted web service.  If the order goes through, then it 
>> needs to notify another web service that fulfills the order.  Once UPS 
>> ships, I need to get that information from UPS.  If all the rules for 
>> the sytem are in the dmbs, can the dbms do all that external stuff? 
>> Perhaps through stored procs?
>>
>> If so, is anyone aware of any open source web applications that do 
>> have all the rules for the system in the database?
>>
>> And to you same people, do you think there's room for "application 
>> databases", where applications (who may or may not use databases for 
>> storing information) talk to each other through well-defined interfaces?
>>
>> Thanks,
>> Joe
> 
> 
> Doing some research, and it looks like it's quite possible.  From 
> Oracle, at least.  Interesting.
> 
> http://www.oracle.com/technology/sample_code/tech/java/jsp/samples/wsclient/Readme.html 

How do you do unit testing on dbms?  Or does such a thing not make sense?


0
joe.vandyk (160)
6/2/2006 4:17:25 AM
On 2006-05-31 11:00:05 -0500, Bob Badour <bbadour@pei.sympatico.ca> said:

> Robert Martin wrote:
> 
>> On 2006-05-30 05:54:52 -0500, "David Cressey" <dcressey@verizon.net> said:
>>> 
>>> What if we destroy all the data up to this point?  Time to update your
>>> resume, everybody!
>> 
>> Granted, granted.  But destroying the data is not the same as isolating 
>> the data management mechanism from the data model.
> 
> More ignorant tripe. Do you even have a clue what a data model is? What 
> sort of data model you are talking about? Without that, what you wrote 
> is not only wrong but essentially meaningless.

MORE IGNORANT TRIPE!!  Wow, such power.  Such articulation.  What a 
masterful command of the language you have. Wow.

So, again, the point I'm trying to make is that applications should be 
designed in such a way that they are decoupled from the DBMS, as well 
as from the detailed schema (i.e. the implementation details of the 
data model)
> 
> 
>> Actually, based on your post, I don't think you disagree completely 
>> with mine.  At most I think you disagree with the emphasis.  My "bucket 
>> of bits" statement is extreme because I am often found in the situation 
>> of helping teams of developers who start their projects by saying: "OK, 
>> we've got Oracle.  Now what?"
> 
> Sadly, I have been paid large sums of money to fix the problems created 
> when teams started with "We've got objects. Woo hoo!" instead.

So have I.  I'm not arguing that data modeling should be ignored.  I'm 
not arguing that DBMSs should not be used.  I'm arguing that the design 
of application programs should be decoupled from the details of the 
DBMS.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/2/2006 5:40:01 AM
On 2006-05-31 12:44:04 -0500, "Marshall" <marshall.spight@gmail.com> said:

> Wow, I missed that one completely. "Isolate the data management
> mechanism from the data model." How in tarnation is the data
> manager doing to manage the data if it is isolated from the
> data model?

It's called decoupling.  Generally it's based on dynamic polymorphism 
which is a lot of syllables that really mean function pointers.  The 
idea is that you write the application program in such a way that it 
can manipulate the data in the data model without coupling it directly 
to the DBMS, or the details of the schema.  The decoupling mechanism is 
very similar to the mechanism used to create device independence in 
operating systems like Unix.

-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/2/2006 5:43:58 AM
On 2006-05-31 13:08:22 -0500, "David Cressey" <dcressey@verizon.net> said:

> 
> "Robert Martin" <unclebob@objectmentor.com> wrote in message
> news:2006053108160577923-unclebob@objectmentorcom...
> 
>> Actually, based on your post, I don't think you disagree completely
>> with mine.  At most I think you disagree with the emphasis.  My "bucket
>> of bits" statement is extreme because I am often found in the situation
>> of helping teams of developers who start their projects by saying: "OK,
>> we've got Oracle.  Now what?"
> 
> 
> I, on the other hand,  have run into a lot of teams who say "we'll worry
> about all that normalization crap when we're ready to start work on version
> 2."

Yes, that would be a mistake.  Once you have decided to use an RDB, you 
need to use it well.  The point is that you can design many application 
programs in such a way that you don't have to make that decision early.
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/2/2006 5:45:36 AM
On 2006-05-31 11:34:36 -0500, Bob Badour <bbadour@pei.sympatico.ca> said:

> With all due respect, what on earth makes you think anything you write 
> is the least bit interesting?

My royalty checks aren't bad.

Anyway my writing must be interesting to you, since you've made at 
least a half-dozen posts in this thread in response to mine.  For my 
part I find the level of ad-hominem (i.e. substanceless) arguments to 
be fascinating.  The raw angst without true argument must be a symptom 
of something, but what?

-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/2/2006 5:51:31 AM
On 2006-05-31 09:14:33 -0500, "Tony Andrews" <andrewst@onetel.com> said:

>> I was doing neither.  I was expounding an attitude about DBMSs that I
>> have found useful over the years.  When I put a system together I treat
>> the DBMS as a detail.  I isolate it from the application code as much
>> as possible.  What results is an application design which is deeply
>> partitioned into areas that know a lot about the DB and areas that know
>> nothing about the DB.  This is just good decoupling.
> 
> Decoupling is good, if done at an appropriate level.  However, given
> your preference for swapping out DBMSs "at a whim" you clearly have no
> choice but to use the lowest common denominator abilities of all DBMSs
> that might be chosen, which probably amounts to some very simple
> low-level DML and SELECT statements.  Then you effectively build your
> own pseudo-DBMS on top of this with application code.  What a waste of
> time and effort, not to mention the money you spent buying a DBMS of
> which you refuse to use 95% of the power!

Finally an argument with some subtance in it!  Thank you!

Yes, it would be a shame if we were unable to utilize the power of the 
tool.  So, what if we put the decoupling level a bit higher than the 
schema.  What if the application defines a set of data management 
services that are implemented by another layer?  What if that layer can 
make use of all the nifty features of the DBMS?  What if that layer 
could also be replaced with a completely different mechanism?
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/2/2006 5:55:14 AM
On 2006-05-31 11:43:43 -0500, frebe73@gmail.com said:

> The conclusion was obvious:
> Continue to embedd (ANSI) SQL in the application, but make your own
> (JDBC/ODBC/ADO) driver on top of the vendor driver, to eliminate the
> remaining incompatibilites between vendors.

Interesting!  Make your own driver.  I like the idea because it gives 
you a lot of control.  However, I would still layer the application so 
that the embedded SQL was confined to the layer that knew about that 
driver.
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/2/2006 5:58:01 AM
On 2006-05-31 13:13:47 -0500, Bob Badour <bbadour@pei.sympatico.ca> said:

>> I was doing neither.  I was expounding an attitude about DBMSs that I 
>> have found useful over the years.
> 
> That you found it useful says more about your intellect than about DBMSs.

Thank you for another very creative ad-hominem argument.  I'm 
collecting them you see.  I've framed them, and have them all up on my 
wall where I can read them and appreciate their simple beauty.
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/2/2006 5:59:37 AM
On 2006-05-31 11:14:52 -0500, "Mikito Harakiri" 
<mikharakiri_nospaum@yahoo.com> said:

> Robert Martin wrote:
>> Ah, it is so easy to generalize about what one person understands.
>> Are you saying that it is "pure unadulterated garbage" that application
>> developers should isolate their application code from the the whims of
>> the API designers at Oracle?
> 
> Database API is SQL.

If only it were so.

> Everything else is auxiliary technology that
> supports it. JDBC is merely a low level programmatic glue between SQL
> and Java, PL/SQL (stored procedures) are the way to enhance SQL with
> programmatic relations (aka functions).
> 
>> Should those application designers use
>> every little cute ORACLE trick and call?
> 
> Sometimes you have no choice. Consider hierarchical queries, for
> example. Would you go through all the trouble learning/implementing
> nested sets/intervals, materialized path etc, or rather write
> relatively straightforward query based on proprietory "connect by" SQL
> feature?

I would write the straightforward query and then hide it in a lower 
layer of the application, so that the rest of the application did not 
need to know about it.

> 
>> Or shoudl they stick to
>> standard SQL as proferred by ODBMS or JDBMS, etc.  Should those
>> application developers scatter embedded SQL all through their
>> application code?
> 
> This is a culprit that OO people stubbornly refuse to understand.
> Embedding high level language (SQL) statements inside low level
> language (Java) is perfectly reasonable. What you propose instead, a
> pathetic set of classes that build the query dynamically?

I propose a set of classes that uses SQL to do the queries.  And then 
restricting those classes to one well defined layer of the application. 
 The rest of the application uses that layer through a polymorphic 
interface so that the layer can be replaced with a different 
implementation when needed.

> 
>> Or should they partition that application code into
>> areas that know about the DB and areas that don't?  Should they strive
>> to make it possible to swap Oracle for MySql or not?
> 
> Writing generic SQL might be a good idea, but sometimes you have to use
> proprietory feature. It saves time in a short term.

Granted.

> 
>> Should they
>> strive even to eliminate the relational flavor of the data from the
>> guts of their algorithms, or not.
> 
> This is rethorical question.

No, it is a very serious question.  Actually it is a serious 
recommendation.  As you climb up the levels in an application program 
you should quickly reach a level where there is no knowledge of SQL.  
At a slightly higher level there should be no knowledge of tables and 
rows.  Soon thereafter the layers don't even know about the relational 
schema, and manipulate the data in the form that is most convenient for 
the application.

-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/2/2006 6:07:14 AM
On 2006-05-31 11:50:20 -0500, "topmind" <topmind@technologist.com> said:

> I don't see how the issue of proprietary SQL is any different than a
> proprietary app language.

It's not.  I want the application to be isolated from the DB; and I 
want the DB isolated from the application.  I wan't the application 
programmers to be able to change from Oracle to MySQL to Flat files.  I 
want the DB to have the freedom to support Java, C#, C++ or Python.

Note the symmetry.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/2/2006 6:10:30 AM
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:11x4awera6xot$.1h8n8lnn1x8j5.dlg@40tude.net...
> On Thu, 1 Jun 2006 17:40:58 +0300, x wrote:
>
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> > news:1qh0bg01l3rh1$.b18js04t02uv.dlg@40tude.net...
> >> On Thu, 1 Jun 2006 15:18:37 +0300, x wrote:
> >>
> >>> No. How can I observe the behavior if there is no data.
> >
> >> Where is a problem with that? What data do you need to observe behavior
of,
> >> say, a real-valued function?
> >
> > I do not know what you call behavior.

> Yet you know what you call data?
Yes. That robot from Star Trek.

> > To answer the question: I need the function.

> exp()

Huh !?!?


0
x366 (42)
6/2/2006 6:17:57 AM
On 2006-05-31 12:26:23 -0500, "Marshall" <marshall.spight@gmail.com> said:

> Robert Martin wrote:
>> On 2006-05-30 17:54:53 -0500, "Marshall" <marshall.spight@gmail.com> said:
>>> 
>>> There are many different contexts in which software is developed.
>>> I will speak relative to enterprise software, which is where DBMS
>>> software is often found. In that context, the above quoted
>>> paragraph is pure, unadulterated garbage. It is not simply
>>> valueless; it is actively harmful. The writer furthermore
>>> demonstrates that he completely lacks any understanding
>>> of what the field of data management is, or what it is for,
>>> or why it is useful.
>> 
>> [...]
>> Are you saying that it is "pure unadulterated garbage" that application
>> developers should isolate their application code from the the whims of
>> the API designers at Oracle?  Should those application designers use
>> every little cute ORACLE trick and call?  Or shoudl they stick to
>> standard SQL as proferred by ODBMS or JDBMS, etc.  Should those
>> application developers scatter embedded SQL all through their
>> application code?  Or should they partition that application code into
>> areas that know about the DB and areas that don't?  Should they strive
>> to make it possible to swap Oracle for MySql or not?  Should they
>> strive even to eliminate the relational flavor of the data from the
>> guts of their algorithms, or not.
> 
> Seven consecutive leading questions and my parser runs out
> of memory. Uh, let's see: yes, as appropriate, ideally (assuming
> you mean JDBC; I don't know what JDBMS is), no-of-course-
> not-I-never-suggested-otherwise, yes, no, probably not.
> 
> (Perhaps we could come up with a better format for dialog.)

Heck no, that was fun!  But I find your answers to be contradictory.  
You say that application developers should not isolate their code from 
the DBMS API, and yet you also say that they should not spread SQL 
throughout their code.  To me those two things are synonyms.

To me, and application should be layered such that the lowest layers 
know about the data management scheme.  If that scheme is relational, 
then that layer knows about SQL, and is the only layer that knows about 
SQL.  Higher layers make use of the abstract services of the lower 
layers.

>> However, I understand both sides quite wall, having done both and been
>> resonsible for both, for damned near 35 years now.
> 
> Your CV is excellent. Mine is too.

Indeed I never once implied otherwise.

If you look back through my posts you will find that I never challenged 
the reputation, intelligence, honesty, or authority of any of the 
posters here.  At most I rendered snide responses to ad-hominem attacks 
against my reputation, intelligence, honesty, and authority.

If we can now both agree that we have worthy CVs, perhaps we can have a 
reasoned debate about issues instead of an ad-hominem pecker-check.

> My point of view is also that of an application developer, because that
> is what the vast majority of my career has been. However I have
> been quite impressed with the achievements of the field of data
> management, and have worked hard to educate myself in it.

As well you should!  As have I.

> I have not noticed the same level of attempting to destroy
> and belittle the achivements of the other side coming from
> the data management camp as I have from the application
> developer camp. (Although I will grant you it occurs.)

I don't know much about that.  If I look at this thread what I see is 
several people flinging insults and derision instead of arguments.  I 
find il-manners instead of reasoned discussion.  And as far as I can 
tell, none of that negative and insubstantial flaming has come from the 
application developer side.  That's not to say that I haven't seen 
flame-wars between app developers, believe me I have.  But they aren't 
evident in this thread.

For what it's worth I don't think either side has better manners than 
the other.  I wish the manners of all posters could be better.  But the 
last twenty years of involvement on newsgroups has convinced me that 
flame-wars and insults are the norm, and reasoned debate the exception. 
 A shame, really.

> I think
> it may have to do with the fact that the dbms people have
> always had to work with application developers, while many
> of the application developers have only recently had to start
> working with the dbms camp.

I don't understand that argument.  From my point of view the two have 
been together (and at odds) for the last two decades.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/2/2006 6:30:27 AM
Robert Martin wrote:
> On 2006-05-31 11:50:20 -0500, "topmind" <topmind@technologist.com> said:
>
> > I don't see how the issue of proprietary SQL is any different than a
> > proprietary app language.
>
> It's not.  I want the application to be isolated from the DB; and I
> want the DB isolated from the application.  I wan't the application
> programmers to be able to change from Oracle to MySQL to Flat files.  I
> want the DB to have the freedom to support Java, C#, C++ or Python.
>
> Note the symmetry.

I note a tremendous *lack* of symmetry!

Java, C#, C++, and Python are comparably expressive, and at
comparable levels of abstraction. (I can hear the screams of
the language advocates already.) Sure, Python has list
comprehensions and C++ has a turing-complete generic type
system, but they're all fundamentally imperative and procedural.

On the other side, you put together Oracle and flat files!
Oracle has natural join; flat files have what exactly? seek()?!


Marshall

0
6/2/2006 6:58:15 AM
Robert Martin wrote:
> On 2006-05-31 12:44:04 -0500, "Marshall" <marshall.spight@gmail.com> said:
>
> > Wow, I missed that one completely. "Isolate the data management
> > mechanism from the data model." How in tarnation is the data
> > manager doing to manage the data if it is isolated from the
> > data model?
>
> It's called decoupling.  Generally it's based on dynamic polymorphism
> which is a lot of syllables that really mean function pointers.  The
> idea is that you write the application program in such a way that it
> can manipulate the data in the data model without coupling it directly
> to the DBMS, or the details of the schema.  The decoupling mechanism is
> very similar to the mechanism used to create device independence in
> operating systems like Unix.

That's a complete non-sequitur from the sentence I took issue with.
You said, "Isolate the data management mechanism from the data
model." This has a very clear denotation: it means the dbms should
not know the schema of the data it is managing. This is clearly
self-contradictory. Perhaps you didn't mean that? Perhaps the
later "it's called decoupling" paragraph is more like what you
really meant to say?


Marshall

0
6/2/2006 7:06:56 AM
Robert Martin wrote:
> On 2006-05-31 11:34:36 -0500, Bob Badour <bbadour@pei.sympatico.ca> said:
>
> > With all due respect, what on earth makes you think anything you write
> > is the least bit interesting?
>
> My royalty checks aren't bad.

LOL.


> For my
> part I find the level of ad-hominem (i.e. substanceless) arguments to
> be fascinating.  The raw angst without true argument must be a symptom
> of something, but what?

"Ad-hominem" doesn't mean "substanceless." You might want to
review the technical definition.

You keep saying there are no arguments, but there have
been plenty of substantial points made by the c.d.t. voices.
It is easy to be distracted by insults when they start flying,
and focus on them exclusively, but the presence of insults
doesn't mean the absence of valid argument.


Marshall

0
6/2/2006 7:10:50 AM
Robert Martin wrote:
> On 2006-05-31 11:14:52 -0500, "Mikito Harakiri"
> <mikharakiri_nospaum@yahoo.com> said:
> >
> > Database API is SQL.
>
> If only it were so.

Here, Robert is clearly saying that SQL is not the database API.
But shortly afterward, in the same thread:

Robert Martin wrote:
> [...] But I find your answers to be contradictory.
> You say that application developers should not isolate their code from
> the DBMS API, and yet you also say that they should not spread SQL
> throughout their code.  To me those two things are synonyms.

Here, Robert is clearly saying SQL *is* the database API.

I am unsure what to make of this.


Marshall

0
6/2/2006 7:22:42 AM
Robert Martin wrote:
> On 2006-05-31 12:26:23 -0500, "Marshall" <marshall.spight@gmail.com> said:
>
> >> [...]
> >> Are you saying that it is "pure unadulterated garbage" that application
> >> developers should isolate their application code from the the whims of
> >> the API designers at Oracle?  Should those application designers use
> >> every little cute ORACLE trick and call?  Or shoudl they stick to
> >> standard SQL as proferred by ODBMS or JDBMS, etc.  Should those
> >> application developers scatter embedded SQL all through their
> >> application code?  Or should they partition that application code into
> >> areas that know about the DB and areas that don't?  Should they strive
> >> to make it possible to swap Oracle for MySql or not?  Should they
> >> strive even to eliminate the relational flavor of the data from the
> >> guts of their algorithms, or not.
> >
> > Seven consecutive leading questions and my parser runs out
> > of memory. Uh, let's see: yes, as appropriate, ideally (assuming
> > you mean JDBC; I don't know what JDBMS is), no-of-course-
> > not-I-never-suggested-otherwise, yes, no, probably not.
> >
> > (Perhaps we could come up with a better format for dialog.)
>
> Heck no, that was fun!

I can vaguely see how it would be, but it tends to obscure the
communication, which runs counter to my goals.


> But I find your answers to be contradictory.
> You say that application developers should not isolate their code from
> the DBMS API, and yet you also say that they should not spread SQL
> throughout their code.  To me those two things are synonyms.

It is the difference between everywhere and somewhere.

We are both discussing layered architectures, and we both
posit a layer "closest" to the database. (We usually call this
a "lower" layer, with the metaphor being that the dbms is
at the bottom, even though an rdbms is using a higher level
of abstraction.)

This layer is part of the application. It is an important part;
perhaps the most important part. It should not, indeed cannot,
be isolated from SQL. This does not imply that SQL will
be present at *every* layer of the code. If you find you
are generating HTML and invoking JDBC in the same class,
you might have a problem with the modularization of your
code, ha ha.


> To me, and application should be layered such that the lowest layers
> know about the data management scheme.  If that scheme is relational,
> then that layer knows about SQL, and is the only layer that knows about
> SQL.  Higher layers make use of the abstract services of the lower
> layers.

Very reasonable, provided the dbms access layers is written to
expose a high-level, high-abstraction interface. If the interface to
that layer is merely getCustomerRecord(), putCustomerRecord(),
etc. then this approach blows chunks. (And unless you do restrict
this layer to that kind of functionality, you won't be able to swap
in a flat file as the data "management" part, without implementing
an entire dbms in the flat-file version of that layer.)


> If you look back through my posts you will find that I never challenged
> the reputation, intelligence, honesty, or authority of any of the
> posters here.  At most I rendered snide responses to ad-hominem attacks
> against my reputation, intelligence, honesty, and authority.

Meh. Early on you called a number of people cowards repeatedly,
and you said their posts were written without their brains. That
qualifies as challenging the intelligence of posters. Also
you've repeatedly labelled as ad-hominem (hence implicitly
dismissing the argument without addressing it) a number of
posts which were not ad-hominem, but merely insulting in tone.
So no, I do not agree with the above, nor with any attempt
to claim high ground. In fact, you lose a point for having
complained about name-calling while calling names.


> I don't know much about that.  If I look at this thread what I see is
> several people flinging insults and derision instead of arguments.

You are mistaken. The thread has contained quite a number of
substantive arguments, some of which were accompanied
with insults and derision. (I do not claim this is ideal.)


> For what it's worth I don't think either side has better manners
> than the other.

Alas, I will have to disagree with you there. My experience is
that the dbms propopents have the noticably worse manners.
Speaking very generally, of course. However I also observe
that they are quite good with logic. I do not claim any
causal relationship between the two observations.


Marshall

0
6/2/2006 7:48:12 AM
Bob Badour wrote:
> Marshall wrote:
>
> > And in swoops the application programmer to "save" the day
> > from the problem he invented! All he has to do is write that
> > subset of a DBMS that he needs today. Which will slowly,
> > over time, increase until it's a badly implemented, bug ridden,
> > ad hoc implementation of half of a database. This is
> > Spight's Law. You have to have a dbms, whether you
> > use a good one or reinvent it yourself, badly.
>
> Man, you sure are pushing hard for a legacy. Do you not intend to number
> your laws? Should we take that as Spight's First Law? Or Spight's Zeroth
> Law? And law of what?

Since I've mentioned it a few times in this thread, it may appear
that I'm "pushing hard." But I coined the phrase in 2002, and
have mentioned it only about ten times since then. I have
never mentioned it in any odd numbered years, for example.

The fact that people routinely massively underestimate the
power and importance of the dbms needs to be publicized.
Because of this, you regularly hear people stating such
ridiculous requirements as wanting to be able to swap
out a dbms for a flat file!

And if we have learned anything from OOP, it is that
a concept is much easier to sell if it has a catchy name!

(Oh, and I'll take "Spight's Zeroth," please.)


> Are we allowed to paraphrase? Like, for instance, would you accept
> someone reworking it to: "Spight's Law: Necessity is the mother of
> re-invention." ?

I like it!


> > PS. Props to Greenspun's Tenth.
>
> You and your obscure references to interesting geeks. You caused me to
> waste an entire afternoon reading various and sundry snippets from
> Greenspun's sites.

Heh. He's quite the writer.


Marshall

0
6/2/2006 8:09:09 AM
Robert Martin wrote:
> On 2006-05-31 09:45:00 -0500, "Marshall" <marshall.spight@gmail.com> said:
>
> > That you completely fail to mention the *primary* uses
> > of a DBMS is telling. Structure, integrity, and manipulation
> > are the central strengths of a DBMS. The pride of
> > application developers (or simply their lack of education)
> > makes them want to reserve these functions for their
> > application code, because that's the only hammer they
> > know how to swing well. But application code is an
> > inferior tool for these.
>
> Dear Marshall,
>
> The soft insinuation that I am ignorant, is really just an ad-hominem
> argument.  The gentle implication that I am part of an arrogant and
> ignorant group is also an ad-hominem.  I encourage you to avoid such
> arguments since you are quite completely ignorant of my knowledge of
> the subject.

"ad hominem": You use that word a lot; I do not think it
means what you think it means.

I have seen no occurances of the ad-hominem logical fallacy
in this thread. Bob has said a few times something along
the lines of, you said this, and this, and this, and it was
all tripe, therefore I say what you write is tripe. This is
not ad-hominem. Generalizing from what someone says
to qualities about that person is not a logical fallacy.
Generalizing from qualities about a person to qualities
about a statement of theirs is.

My response to what you write about the correct way to
write applications that manage data is that it is fundamentally
incorrect, and misunderstands the proper role and use
of a dbms. Now, it may be the case that you in fact don't
believe what you're writing and really *do* know those
things, but decline to do so for whatever reason. However
I'm going to go out on a limb and claim that you don't
know, or misunderstand.

I do not then conclude that you are ignorant about everything,
and in fact I am willing to grant that you probably know
a great deal about application development and OOP.
However, when you then move out of that arena and in
to the field of data management, and expound harmful
and regressive ideas there, I am moved to offer up
my version of Huxley's rebuke to bishop Wilberforce.
If the ladies in the gallery faint, so be it!

[moved paragraph]

> I'm an old hand at many different languages and programming schemes.
> Along with all the standard application languages, I've studied and
> used languages like Prolog, Forth, Snobol, etc, etc, etc.  I drew my
> first ER diagram over 20 years ago, when I already had 15 years of
> exeperience behind me, and have since used many different RDBs, in many
> different environments.  I have designed reactive systems driven by
> triggers, and I have designed imperative systems driven by top down
> functions.   I have worked in MIS environments and embedded real-time
> environments.  I have worked on shrink-wrapped software, and
> mathematical modeling software.
>
> In short, if my way of viewing the world is "stunting" it is not
> because I haven't been learning as much as I can about as much of this
> industry as I can for the last 35 years.
>
> Oh and by the way, that last paragraph was also a subtle ad-hominem
> argument about what "it appears" my opinions might be and how they
> might be stunting.

I am not sure why you keep bringing up your background; I
have already stipulated that your CV is excellent. Mine is
comparable. I could also note that, knowing what I do about
bell curves, that I am probably taller than you, and can
probably leg press more. Neither that, nor your experience
level, is relevant to the discussion of how to manage data,
and to suggest otherwise *is* an ad-hominem logical fallacy.


> SO.......

> In the midst of the ad-hominems I think you made a good point.  I did,
> in fact, underlay the role of the DBMS.  I don't think you followed
> through on that point though.  In what way does the importance of the
> DBMS impact on my assertion that the application design should not know
> about the details of the DBMS.  Do the attributes of data integrity and
> manipulation mean that the application code should strongly couple
> itself to the details of the DBMS?

and

> Let's see if we can drive this back to substance.  Instead of telling
> me all the things that are wrong with my upbrining, tell me what's
> wrong with my assertion that application design should be decoupled
> from database design.

Very good.

I am going to narrow the terminology down, because what you
ask depends on the definition of the rather loose terms "details
of the DBMS" and "database design" and "decoupling."

If you are talking about things like what kind of indexing technique
does the dbms uses, or the layout in memory of the tables, then
of course the application should be decoupled from these things,
and it is by default. (In fact, I'm not sure how you *could* couple
them if you wanted to.) I do not expect that is the sort of thing
you're talking about.

I think what you mean by "database design" is specifically the
logical schema of the database: the tables and their attributes.

Should the application be decoupled from these? No, it should
not, and in fact it cannot. The application necessarily has to know
what logical data structures are in use, and it has to know it
pretty much everywhere. The schema is immanent in the
application; if it wasn't, we could end up with some
frankensteinian chimera that thought it was a word processor
in one place, an accounting package in another, and a
device driver in a third.

Consider: what does it mean to decouple two modules? It means
to reduce unnecessary dependencies between them. It does not
mean to remove all dependencies. If they had *nothing* in common
they could not work together at all.

What *do* they have in common? What *must* they have
in common? An agreed-upon interface.

So: what is the agreed-upon interface between the dbms and
the application that uses the database? The schema.

We also have the issue of a data-access layer. This might
be a layer that invokes jdbc directly, for example. Might we
want to enmodularize this code? Okay, that's not really a word,
but might we want to confine the jdbc to a single module or
group of modules? Sure. And of course this module must
have an interface. What shall it look like?

If it is something that could easily be reimplemented in
terms of a flat file, or XML-DOM, then you've blown it.
You've castrated the dbms, and now you run into
the full force of Spight's Law, because you haven't done
anything to address the problems of data management.
You can't make issues of integrity enforcement and
data manipulation, transaction processing and concurrent
access, etc. go away just because you wield the
Mighty Sword of Decoupling. All that buys you is better
maintainability of your code; it doesn't actually implement
any features. Now you have to go and implement the
half of a database that you would have used.

If, on the other hand, the interface to this layer is
very high level, application-specific stuff, then
maybe you did a good job.


Marshall

0
6/2/2006 8:44:10 AM
Robert Martin wrote:
> Bob Badour wrote :
> > And this is why I say that what you write is such
> > ignorant tripe.
>
> Ah, back to the ad-hominems.

Obviously you do not know what ad hominem is. What BB wrote
may be called an /insult/ but it is not ad hominem since it
is not even an argument. Ad hominem refers to a fallacious
form of /argumentation/. BB's argumentation followed that
insult. The insult was not his argument. Do you understand?
You are not alone in this increasingly common misconception
that insult = ad hominem.

> > 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

So you agree that, unlike a relational data model, an OO
(Network) data model imposes expression bias? In other
words, that it creates a asymmetric navigational structure
that artificially makes some computations more difficult to
express? And do you think this is good? If so why?

> 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.

As JMD also pointed out, your choice of filesystems (as in
hierarchal filesystem which is clearly what you meant) is a
TERRIBLE one. That you find hierarchal file systems "work
quite well" shows a HUGELY different assessment relative to
MANY other people. No need to rehash the problems with
hierarchal systems yet again, but surely you must have
noticed at least some of them from a user perspective?

> There is no hue and cry for our filesystems to suddenly be
> RDBs.

Umm ... Haven't you noticed the renewed drive towards
searching (querying)? For example Google, Google Desktop,
iTunes, Spotlight, Aperture? Have you even heard of WinFS?

-- Keith --

0
duggar (292)
6/2/2006 10:03:35 AM
On 1 Jun 2006 14:41:07 -0700, Mikito Harakiri wrote:

> Dmitry A. Kazakov wrote:
>> On 1 Jun 2006 13:07:49 -0700, Mikito Harakiri wrote:
>>
>>> Dmitry A. Kazakov wrote:
>>>> Operations on functions (subprograms):
>>>
>>> These are easily defined in the realtional world (where we consider a
>>> function as a relation)
>>>
>>>> 1. Mapping (call to) the tuple of arguments to the tuple of results
>>>>
>>>>    Map : f x x1 x  x2 x ... x xN -> y1 x y2 x ... x yN
>>>
>>> Calling a function f(x,y) with two arguments x=1 and y=2 is relational
>>> join of three relations:
>>>
>>> 'z=f(x,y)' /\ `x=1` /\ `y=2`
>>>
>>> projected to attribute z.
>>
>> Where you get z for all possible x and y?
> 
>>From an index that corresponds to a function. Similar to index range
>>scan that brings tuples from an ordinary relation, a function index
>>allows to eavaluate only a portion of an (infinite) relation.
> 
>> Another problem is that this is untyped.
> 
> Relation attributes are typed.

It is not same. A type error in a function argument does not make the
statement above illegal.

>> You can do it externally, but it should be a function property.
> 
> I can express the constraint that relation R(x,y,z) is a function in
> relational terms -- that is all what is needed.

Yes. Object is an ordered pair (type, value). You could add types as
"columns". That would get you some sort of dynamic typing for poor. But it
isn't static. Then it is not clear how are you going to bridge static and
dynamic typing. You need values of types, literals of, equality of. Then
sets of types and classes come, also with literals?

>> The third problem is that
>> you need "=" for all things as well as literals for all things. It is a can
>> of worms. Especially function literals aren't easy. What is a literal of
>> sine?
> 
> Once again, a relation which is a function needs an index that would
> make evaluating relational expressions containing functions practical.
> Literals are not required. Whether the equality relation is needed is a
> deep issue.

Yes. It is the essence of the OO-RM dispute, as I see it.

Behavioral view does not require either literals or equality. Both are
represented as behavior. So literal is a parameterless function: 1:�->N,
"abc":�->String. Equality is a symmetric binary Boolean-valued function.
You can define them as and when you wish. If you want 1 is to return the
standard input stream, be it so. It isn't a language question.

[ What I really don't understand, is why DB guys so stick to their sacral
data. Relational algebra can handle anything exposing a corresponding
minimal behavior: has "=", "<" and a copy constructor. ]

>> This is non-constructive. Are you going to compare all inputs and outputs?
>> Even if they model uncountable sets?
> 
> This is an interesting objection. While the question if the two
> functions are equivalent is certainly important from relational engine
> perspective (otherwise how would you do optimization?), it remains to
> demonstrate that the end-user migh ask this question as well.

Ooch, how do you know what will be asked? The formalism shall either forbid
the very question, or else give a reasonable answer to. If functions are
comparable they must be.

Behaviorally it is not a problem at all. Don't provide "=" if you cannot
implement it. You will loose some types of containers with that, but that's
your choice. The language will make all statements about these containers
illegal.

>>>> 4. Copy (for marshaling, closures etc)
>>>>
>>>>    := : f -> f
>>>
>>> Copying is not a logical operation.
>>
>> It is. You should consider the computational state as an additional
>> parameter:
> 
> Computational state is not logical concept.

State is an element of a proper set. That makes ":=" "immutable", i.e. a
standard function. No magic in.

>> It can be specified through relations, of course.
>> Anything can be.
> 
> Specifying "everything" through relations is not as easy as your
> sentence might sound.

I don't care, because it is quite obvious that even if you get things
described as relations, that would not get you a reasonable implementation
of. You can neither effectively translate it to existing machine languages,
nor create a relational hardware (here I mean things like quantum
computing). The notation itself is very heavy for mortals.

What is needed is a formalism capable to describe not only a Turing
machine, but also C/C++ and SQL in a conceivable manner. Relations don't
fit well. They have too low abstraction level.

RM fanatics might claim that C/C++ does not deserve any attention, being a
crap. I don't like it either, but it is not a serious argument. Software
written in C/C++ works [sometimes (:-))], that's reality to face. Why it
works, how it does, when it will stop working, how a better language should
look like?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/2/2006 10:12:11 AM
In article <LUKfg.16278$A26.376787@ursa-nb00s0.nbnet.nb.ca>,
Bob Badour  <bbadour@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.

In my (admittedly limited) experience, LDAP seems to be rather successful 
and working fairly well for its intended purpose. 

>> 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.

Not every RDBMS has 'very powerful and transparent authentication and 
security features'.

However, if it is known that one will be using a specific RDBMS that does 
have them, then yes, one could indeed use those. But since different 
RDBMS:es may offer these services through different interfaces, it would 
still make sense to place any such code in pluggable modules, so that the 
application would be using a single, shared interface, that would be 
implemented as necessary for each possible user authentication service, 
whether using LDAP, ORACLE, flat files, or something else.

>>>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.

If you have any part of any system that may need to vary, then having a 
well-defined interface to that part of the system, and having all 
interaction with that part go through that interface, is just a generayy 
good idea. And using a higher level of abstraction means that you are 
hiding unnecessary implementation details, which is also usually 
considered a good thing.

>> ... 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? 

People build higher-level abstractions on top of lover-level ones all the 
time. I fail to see what problem you are having?

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

I advocate using the proper tools for the job, using the most appropriate 
level of abstraction, keeping separate parts of the system separate (and 
potentially pluggable).

If you're writing an embedded application in assembly language, but you 
have available to you a library that is written in a higher-level 
language, then you may well end up implementing something that uses 
higher-level abstractions than in either assembly language or the 
procedureal or object-oriented or otherwise higher-level language that the 
library is written in. 

>  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? 

the process of designing it well, which includes looking at the 
requrements that the different parts of the system have on each other, and
putting together interfaces that expose the necessary functionality, but 
without intermingling the details that don't need to be shared, thus 
decoupling the implementations from one another.

>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?

When an interface is clearly, succinctly and precisely defined, as well as 
offering the necessary functionality in a useful and usable manner, 
without leaking implementation details unnecessarily.

>>>(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" ? 

Not in itself, no. Had I written "Way cool, man!" then perhaps that 
inference would be warranted, but I didn't. I meant 'cool' in the 
colloquial sense of 'OK', or in this specific case, 'I'm glad you managed 
to solve your problem in a way that worked for you'.

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. Had a 
higher-level interface been used instead, then the first implementation 
(which would have called the stored procedures) could have been replaced 
straightforwardly by the second implementation (which implemented that 
functionality in Java), but without having to 'intercept' the 'execute 
procedure abc()' calls.

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

I don't aim for 'cool' solutions. I aim to solve problems, and to have toe 
solutions to those problems work well. Sometimes, as a side effect, those 
solutions can be 'cool', sometimes even 'elegant' (and 'elegant' is 
something I do strive for, unless it conflicts with other more important 
goals).

Why do you focus so on that single word?

Best wishes,

// Christian Brunschen
0
cb5180 (38)
6/2/2006 10:21:59 AM
In article <wIKfg.16269$A26.376462@ursa-nb00s0.nbnet.nb.ca>,
Bob Badour  <bbadour@pei.sympatico.ca> wrote:
>Christian Brunschen wrote:
>> In article <lsBfg.3076$%86.209@trndny04>,
>> David Cressey <dcressey@verizon.net> wrote:
>> 
>>>"Christian Brunschen" <cb@festis.df.lth.se> wrote in message
>>>news:e5mir9$gug$1@news.lth.se...
>>>
>>>>For a trivial example, consider an application that needs to somehow
>>>>authenticate users [ ... ]
>>>
>>>What makes the example trivial?  Do you mean trivial in the sense that
>>>mathematicians use the word, in the sense that engineers use the word,  or
>>>in the sense that common parlance uses the word?
>> 
>> In a very loose common parlance sense of the example being easy to come up 
>> with, not being contrived and thus something that people do occasionally 
>> encounter.
>
>You left out the part where it was not very illuminating either. 
>Assuming one decides that forgoing the authentication system built into 
>every dbms is a good idea in the first place, authentication lends 
>itself to a simple predicate (using the computer programming definition) 
>or similarly simple subroutine regardless.

For one thing, not all RDBMS:es offer authentication services; for 
another, not all of them offer them in exactly the same way. Either way, 
it still makes sense to create an interface used by the application and 
implemented in whatever way necessary by the pluggable implementation, 
whether it uses LDAP, ORACLE, MySQL, Derby or something else.

>Your argument is as valid as stating one should create a square root 
>function to isolate the program from numerical methods or a distance 
>function to isolate the program from your choice of square root function.

If you have the option of using different math libraries (that might use 
different algorithms, offer different precision or similar), then that 
would indeed be an excellent thing to do, wouldn't it?

>While I consider the separation of concerns a sound design principle, 
>your argument leaves me uncertain as to what concerns you intend to 
>separate.

Wherever it makes sense to separate concerns, they should be. It makes the 
code more maintainable and robust in the face of change.

Best wishes,

// Christian Brunschen
0
cb5180 (38)
6/2/2006 10:34:29 AM
Bob Badour ha escrito:

> To be fair, you did not actively debunk what he wrote.

Bob, I (and others) did that many times in the past. His position is
not new and it is shared by others.

> To an educated
> and informed person, what he wrote was incoherent on its face,

Indeed. An to the uninformed readers of comp.object, it could be
interesting to know that many database experts consider what he wrote
about databases as plain nonsense.

> But the sad truth is: I am certain he lacks the cognitive ability to
> recognize just how incoherent what he wrote is. I am sure he believes he
> wrote something coherent that deserves more effort.

I have no doubts about this.


Regards
  Alfredo

0
alfredono (16)
6/2/2006 11:08:57 AM
Bob Badour ha escrito:

> They entertain and they communicate jargon for people to use to signal
> they are 'in the know'. Some people are masters at inserting meaningless
> gibberish into a conversation to impress others.

There is a name for this:

http://en.wikipedia.org/wiki/Technobabble


Regards
  Alfredo

0
alfredono (16)
6/2/2006 11:19:51 AM
Bob Badour ha escrito:

> > One could argue that to the UI programmer, the database is a "bit
> > bucket" (very ugly term) of which he/she needs to know little.
> > However, the UI is probably only 10-20% of the code, with 80-90% being
> > the database application code - and to write this well you need to know
> > your DBMS.

This is what usually happens when you write a DBMSless application or
you misuse a DBMS as a dumb file system.

> Actually, you have that backward. In my experience, the combination of
> exception-handling and user-interface code account for well over 90% of
> the code in a typical 3gl/4gl application.

This is what happens when you use a DBMS properly. The size of the UI
code is aproximately the same, but the size of the business rules code
is reduced in orders of magnitude.


Regards
  Alfredo

0
alfredono (16)
6/2/2006 11:31:55 AM
Guys:

Consider two projects, both with a DBA.

Team A carefully partitions all modules, including the DB-facing ones.

Team B scatters SQL hither and yon.

Now in both teams, the DBA owns all access to the database, and is the only 
one authorized to change its schema.

Team A, however, can sack its DBA any time they feel like, and can easily 
replace the DB-facing modules with some other system.

Team B's DBA is the lord of all he surveys. He or she has perfect job 
security, and a lot of clout in the team's decisions.

So what's the /real/ motivation for this thread, guys? ;-)

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!! 


0
phlipcpp (2771)
6/2/2006 11:38:22 AM
Joe Van Dyk wrote:

> Alfredo Novoa wrote:
>> Robert Martin wrote:
> 
> <snip>
> 
> Question for the "the system's behavior needs to be in the dbms" people:
> 
> My current view of a dbms is that it's a place to store stuff.
> Obviously, it can be much more than that.
> 
> Say I'm writing an e-commerce website.  I'm restricted to cheap and/or
> free databases, but feel free to assume that I'm not.

I use PostgreSQL, a free database.  It supports "everything that matters". 
It is a little weak IMHO on admin tools, but the 3rd party admin tool
pgAdmin3 is coming along (looks like Microsoft SQL Server's enterprise mgr
and query analyzer).

Postgres delivers everything that SQL Server and DB/2 did, though sometimes
there is a different word for it, or it requires a different approach.

> 
> The credit card supplied with the order needs to be verified against an
> external encrypted web service.  If the order goes through, then it
> needs to notify another web service that fulfills the order.  Once UPS
> ships, I need to get that information from UPS.  If all the rules for
> the sytem are in the dmbs, can the dbms do all that external stuff?
> Perhaps through stored procs?

Yes.  Postgres in particular supports stored procedures in perl, with one
particular mode that allows unlimited access to the system.  Myself I
prefer to use PHP, and you can also code triggers and sprocs in that,
though it is not as mature as the perl system.

Once you can code routines that can "see" outside of the database, you can
more or less do anything.

> 
> If so, is anyone aware of any open source web applications that do have
> all the rules for the system in the database?

<shameless self-promotion>
How about ours?  

http://docs.secdat.com.

Our project, Andromeda, is now very mature in the area of derivations of
many sorts inside a database.  We have found that nearly all common
"business logic" can be resolved into a handful of common repeating
patterns.  The product allows you to specify column and table automations
of various forms so that the server takes over most (and in many cases all)
of the processing.

The motto of the project is "The server implements all business rules at all
times".  

W/respect to making calls to outside services, we are still doing that in
code because we haven't settled on an architecture for it yet that will
likely run on multiple server platforms.  We've seen several cases in work
that comes our way, but not enough yet to generalize.

</shameless self-promotion>

> 
> And to you same people, do you think there's room for "application
> databases", where applications (who may or may not use databases for
> storing information) talk to each other through well-defined interfaces?
> 

SQL is a well-defined interface.  Using triggers and sprocs you can have a
database make a query to any other database anywhere in the world.  

The limitations tend to be political, not technical.  If you are working
with a 3rd party that is big and powerful, then you accomodate them and
whatever interface they've chosen.  

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)
0
6/2/2006 11:38:24 AM
> If you have the option of using different math libraries (that might use
> different algorithms, offer different precision or similar), then that
> would indeed be an excellent thing to do, wouldn't it?

Yes, in some cases it would be an excellent idea, but why don't we
normally separate math libraries? Because the cost is higher than the
benefits in most cases. It's exactly the same with separating SQL
statements. It is a cost associated with that separation. In some cases
the it may be resonable to pay the effort, but mostly it is not.

Fredrik Bertilsson
http://frebe.php0h.com

0
frebe73 (444)
6/2/2006 11:43:48 AM
"Cimode" <cimode@hotmail.com> wrote in message
news:1149195637.347974.125680@h76g2000cwa.googlegroups.com...
> Thank you for your feedback...
>
> <<Bad duplicate treatment can be avoided by
>  judicious use of primary keys and the "distinct" feature>>
> Absolutely. However these are turnaround solutions to insure the
> integrity of data that are to implemented in applicative DBMS code when
> they should be dealt with by the DBMS.  As a result, during system life
> cycle what should be done once is often done each time a new view is
> defined which defeats the purpose of a DBMS.

And what is the purpose of a DBMS? (in this context)

>  A practical problem
> arising happens for instance when a developper leaves a company.  If
> this developper has participated in the design (or lack of design)
> process then this developper is probably aware of all the special
> conditions and features he should add (DISTINCT, IS NULL IS NOT NULL)
> to make count results correct.

That's poor design.  When a poor designer leaves a company, a lot of the
damage becomes apparent.
The problem arose when the company accepted the poor designer's work.

Proper use of DISTINCT is not some "clever, wierd trick"  that only one
developer knows.  It's part of the knowledge shared by ALL competent
database designers who appreciate the power and simplicity of the relational
model and also, for one reason or another, are using SQL.

Perhaps you could tell me which  results ARE correct?  When working on
databases I've designed,  I rearely if ever need to "correct the count".
It's already right,  because it's counting things that are there.




>  But as soon as this developper leaves
> the company his knowledge often get lost which in most cases will make
> the next generation of count queries return false results because the
> new developper will not be necessarily aware of the conditions required
> to make results correct.  In a word the use of features such as
> distinct are already meaning a failure on a relational standpoint.  In
> the case of DISTINCT, their suggested use was made by Codd as a warning
> about that limitation.
>

Yes, but....  If you compare SQL with available alternatives,  it comes off
looking well.

If you compare it with what ought to be built,  it's defective,  as Codd
pointed out.


> <<NULLS are handled pretty well by SQL>>
> The problem is not whether NULL values are well handled by SQL, the
> problem is that NULL values are SQL's only way of representing missing
> information and that this way is a poor one because relational
> predicate logic suporting relational model does not support on three
> valued logic on which SQL NULLS are essentially based.
>

SQL NULLS and three valued logic are separable.  It isn't hard once you get
the hang of it.
I like two valued logic, myself,  and shun three valued logic in SQL.  OTOH,
I recognize that, due to real world limitations,  every now and then I have
to deal with data that isn't there.  It can be done.








0
dcressey (35)
6/2/2006 12:05:55 PM
On 2006-05-31 13:12:49 -0500, Bob Badour <bbadour@pei.sympatico.ca> said:

<<lots of insults, swearing, angst, and derision, but no arguments>>

Bob, when you think of an argument, let me know.  Let me remind you of 
the topic of the argument:

Should application developers design their applications such that the 
DBMS is strongly decoupled from the high level policies of the 
application?  If not, why not?

To say this a different way, should a good application be designed in 
layers such that some of those layers know about SQL and APIs like 
JDBC; while higher level layers know nothing of those details and 
depend upon services of the lower layers?


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/2/2006 12:22:31 PM
Marshall wrote:
> Robert Martin wrote:
> 
>>On 2006-05-31 12:44:04 -0500, "Marshall" <marshall.spight@gmail.com> said:
>>
>>>Wow, I missed that one completely. "Isolate the data management
>>>mechanism from the data model." How in tarnation is the data
>>>manager doing to manage the data if it is isolated from the
>>>data model?
>>
>>It's called decoupling.  Generally it's based on dynamic polymorphism
>>which is a lot of syllables that really mean function pointers.  The
>>idea is that you write the application program in such a way that it
>>can manipulate the data in the data model without coupling it directly
>>to the DBMS, or the details of the schema.  The decoupling mechanism is
>>very similar to the mechanism used to create device independence in
>>operating systems like Unix.
> 
> That's a complete non-sequitur from the sentence I took issue with.
> You said, "Isolate the data management mechanism from the data
> model." This has a very clear denotation: it means the dbms should
> not know the schema of the data it is managing. This is clearly
> self-contradictory. Perhaps you didn't mean that? Perhaps the
> later "it's called decoupling" paragraph is more like what you
> really meant to say?

Marshall, the nonsense in the 'decoupling' paragraph is no better. He 
once again demonstrates that he is completely ignorant of what a data 
model is and of what sort of data model he is talking about.

Whether the functions are statically bound, dynamically bound or even 
dispatched through some completely different mechanism like RPC, a 
message queue, a pipe (named or otherwise), or a shared file is totally 
irrelevant to the issue of decoupling.

He is an incompetent self-aggrandizing ignorant. He has proved beyond 
any possible doubt that he no longer deserves any benefit of any doubt. 
He is an idiot.
0
bbadour (434)
6/2/2006 12:23:07 PM
On 2006-05-31 12:24:44 -0500, Joe Van Dyk <joe.vandyk@boeing.com> said:

> Mikito Harakiri wrote:
>> Robert Martin wrote:
>> 
>>> Application developers get into trouble when they DONT treat the
>>> database as a detail.
>> 
>> 
>> Robert, you claim 35 years of application programming experience. Have
>> you ever come across a performance problem when database is accessed
>> via API
>> 
>> getItemIdList
>> getItemDetail
>> 
>> so that a single jsp page issued a hundred SQL statements instead of a
>> single one? Come on, this one is so common that it surfaces on every
>> performance meeting.

Have I come accross it?  Sure.  Do I think it's good design?  No.  The 
JSP page shouldn't be making low level service calls like that.  The 
JSP page should make a few high level calls to the application, and the 
application should set up the data structures that the JSP needs to 
display.  Then the JSP can make very simple accessor calls into that 
data and display it as needed.

> 
> This problem is easily solved via caching.

I would not have the JSP repeat the SQL many times, either directly or 
through calls to simple minded accessors.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/2/2006 12:27:39 PM
Robert Martin wrote:
> On 2006-05-31 09:14:33 -0500, "Tony Andrews" <andrewst@onetel.com> said:
>
> >> I was doing neither.  I was expounding an attitude about DBMSs that I
> >> have found useful over the years.  When I put a system together I treat
> >> the DBMS as a detail.  I isolate it from the application code as much
> >> as possible.  What results is an application design which is deeply
> >> partitioned into areas that know a lot about the DB and areas that know
> >> nothing about the DB.  This is just good decoupling.
> >
> > Decoupling is good, if done at an appropriate level.  However, given
> > your preference for swapping out DBMSs "at a whim" you clearly have no
> > choice but to use the lowest common denominator abilities of all DBMSs
> > that might be chosen, which probably amounts to some very simple
> > low-level DML and SELECT statements.  Then you effectively build your
> > own pseudo-DBMS on top of this with application code.  What a waste of
> > time and effort, not to mention the money you spent buying a DBMS of
> > which you refuse to use 95% of the power!
>
> Finally an argument with some subtance in it!  Thank you!
>
> Yes, it would be a shame if we were unable to utilize the power of the
> tool.  So, what if we put the decoupling level a bit higher than the
> schema.  What if the application defines a set of data management
> services that are implemented by another layer?  What if that layer can
> make use of all the nifty features of the DBMS?  What if that layer
> could also be replaced with a completely different mechanism?

What sort of things would this layer do?  In my world it would perform
business logic, with procedures for actions such as "create employee",
"calculate payroll".  However I suspect in yours these would be
DBMS-agnostic OO methods, and this layer would be doing something lower
level - though I can't quite imagine what other than generic "insert
[row] into [table]" type commands.

0
andrewst1 (87)
6/2/2006 12:28:55 PM
Robert Martin wrote:

> 
> Should application developers design their applications such that the
> DBMS is strongly decoupled from the high level policies of the
> application?  If not, why not?

PFMJI, Can you describe what a "high level policy" of an application is that
can be decoupled from the database?  What is a high level policy as
distinguished from the commonly used term "business rules".  


-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)
0
6/2/2006 12:33:02 PM
Marshall wrote:

> Robert Martin wrote:
> 
>>On 2006-05-31 11:34:36 -0500, Bob Badour <bbadour@pei.sympatico.ca> said:
>>
>>>With all due respect, what on earth makes you think anything you write
>>>is the least bit interesting?
>>
>>My royalty checks aren't bad.
> 
> LOL.

I guess this means somebody out there is stupid enough to pay him for 
the ignorant nonsense he spreads. That doesn't surprise me. If he had 
any moral character, though, he would refund the money just out of shame.
0
bbadour (434)
6/2/2006 12:35:06 PM
Bob Badour <bbadour@pei.sympatico.ca> writes:
> Marshall, the nonsense in the 'decoupling' paragraph is no
> better. He once again demonstrates that he is completely ignorant of
> what a data model is and of what sort of data model he is talking
> about.

     How does he demonstrate that?

> He is an incompetent self-aggrandizing ignorant. He has proved
> beyond any possible doubt that he no longer deserves any benefit of
> any doubt. He is an idiot.

     You've been claiming this and hurling similar insults throughout
this thread.  I have yet to see you prove it.  If Mr. Martin's claims
are so foolish, it should be a simple matter for you to show how they
are foolish without resorting to schoolyard vernacular.

     You might have valid points to make, but based on your behavior
in this thread I doubt it.  Your posts give the impression that you
are threatened by and frightened of something.  What is it?

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.    | The experts in large scale distributed OO
                         | systems design and implementation.
          pjm@spe.com    | (C++, Java, Common Lisp, Jini, CORBA, UML)
0
pjm (703)
6/2/2006 12:36:36 PM
On 2006-05-31 11:41:54 -0500, Bob Badour <bbadour@pei.sympatico.ca> said:

> Robert Martin wrote:
>> On 2006-05-30 07:51:15 -0500, "CMCC" <c_jackal@hotmail.com> said:
>> 
>>> Robert Martin wrote:
>>> 
>>>> No, a DBMS is a bucket of bits with some low level rules to manage
>>>> those bits.  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.
>>>> 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.  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.
>>> 
>>> No, a OO application is a bucket of bits with some low level rules to
>>> manage
>>> those bits.  An DBMS provides the beavior that the customer
>>> wants to see.  We can completely eliminate the OO application and
>>> replace it with
>>> another of an entirely different form (non OO for example) and
>>> still have all the business behavior we need.
>>> 
>>> The people who sell OO applications have sold you, and the industry, a
>>> misconception: that the OO application is the heart of the system.
>>> This is
>>> flawed.  The heart of the system is the DBMS.  The OO application
>>> 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.
>> 
>> Let this be a lesson to all you cowards who resort to ad-hominem 
>> attacks and name calling.
> 
> Ad-hominem attacks like calling someone a coward? Idiot.

Yes, the use of the term "coward" was pejorative and probably less then 
professional.  Frankly I was pissed off, though I think I had cause.  
The level of derision to an honest post was just so shrill.  In any 
case it IS cowardly to fall back on claims of ignorance and stupidity 
rather than use reasoned arguments.  It's a way to feel superior 
without having to do any of the work.  It takes courage to actually 
make and defend an argument.

Finally, you will note that I have responded with arguments and 
discussion to everyone who has offered the same to me; even those who 
have also flamed me. You will also note that I have not dismissed 
anyone's argument with an ad-hominem attack on the argument.  The only 
ad-hominem I used was the term "coward" and that was not used as a way 
to discredit anyone's position on the issues.  It was used as a way to 
discredit their position on ME.

> <<ad-hominems elided...  Still waiting for reasoned arguments>>

Is it that hard to accept that I might have a reasoned and valid 
position; and that the problem we are having is communication rather 
than intelligence?
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/2/2006 12:41:48 PM
"phlip" <phlip2005@gEEEmail.com> wrote in message
news:pan.2006.06.01.21.15.18.59187@gEEEmail.com...
> Bob Badour wrote:
>
> >> An application should have its SQL statements in only a few modules,
and
> >> all others should be SQL-free.
> >>
> >> Note in my statement, you can replace SQL with GUI, XML, ORB, etc, to
> >> generally the same effect. The point of modules is to isolate and
> >> encapsulate.
&g