Re: Databases as objects
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 02 Jan 2007 16:06:26 GMT
Message-ID: <6qvmh.39636$cz.585402_at_ursa-nb00s0.nbnet.nb.ca>
>>kvnkrkptrck_at_gmail.com wrote:
>>
>>><snip great example>
>>
>>Congratulations on that performance improvement. That is an excellent
>>example of cohesiveness--individual responsibility--something doing for
>>itself what other can not do (as well).
>>
>>We have no disagreement and our approaches are not in conflict with each
>>other. Our system has similar jobs that run entirely inside the
>>database. We still create procedures for them, but they are not called
>>by application programs. They are relatively large SET processing tasks
>>that can only efficiently be executed on sets. They are not
>>transactions. They have nothing to do with OLTP.
>>
>> From what you described, your job didn't really have anything to do
>>with an application trying to hydrate or dehydrate objects from the the
>>DB, or execute transactions either (something that must be done
>>1000/minute), or require an external stimulus, like a customer, to
>>initiate it.
>>
>>I understand what you are saying. I've done it before and I do it
>>still. But I'm still having a communication problem in c.d.t. I
>>actually think its a form of stereotyping: no matter what I say, because
>>it uses the term "object" prejudice thinks I want to replace set
>>processing with Java then take your little sister to the wrong side of
>>the tracks.
>>
>>I'm going to have to work on some examples so c.d.t. can see that what I
>>propose to do doesn't require OOPLs or abandoning set processing.
Date: Tue, 02 Jan 2007 16:06:26 GMT
Message-ID: <6qvmh.39636$cz.585402_at_ursa-nb00s0.nbnet.nb.ca>
kvnkrkptrck_at_gmail.com wrote:
> Thomas Gagne wrote: >
>>kvnkrkptrck_at_gmail.com wrote:
>>
>>><snip great example>
>>
>>Congratulations on that performance improvement. That is an excellent
>>example of cohesiveness--individual responsibility--something doing for
>>itself what other can not do (as well).
>>
>>We have no disagreement and our approaches are not in conflict with each
>>other. Our system has similar jobs that run entirely inside the
>>database. We still create procedures for them, but they are not called
>>by application programs. They are relatively large SET processing tasks
>>that can only efficiently be executed on sets. They are not
>>transactions. They have nothing to do with OLTP.
>>
>> From what you described, your job didn't really have anything to do
>>with an application trying to hydrate or dehydrate objects from the the
>>DB, or execute transactions either (something that must be done
>>1000/minute), or require an external stimulus, like a customer, to
>>initiate it.
>>
>>I understand what you are saying. I've done it before and I do it
>>still. But I'm still having a communication problem in c.d.t. I
>>actually think its a form of stereotyping: no matter what I say, because
>>it uses the term "object" prejudice thinks I want to replace set
>>processing with Java then take your little sister to the wrong side of
>>the tracks.
>>
>>I'm going to have to work on some examples so c.d.t. can see that what I
>>propose to do doesn't require OOPLs or abandoning set processing.
There is no stopping the invincibly ignorant. - DT
>>--
>>Visit <http://spam removed>
>>to read my rants on technology and the finance industry.
Kevin,
Why are you advertising this moron's site? Received on Tue Jan 02 2007 - 17:06:26 CET