Re: Can two sessions be bound in Oracle ?

As often with newgroups, it is not possible to present the complete problem and context of the problem. So misunderstandings will rise, on one side or on both sides.

First of all we are in the process of making "Design Patterns" and they are object based. We do not have a design yet to be "that is rotten at its core". But some techniques have been proposed that some people consider it an "obscure solution".

But I am taking a step back and try to look (and represent) our situation. Allthough "From 50,000 feet up" is a bit high for me.

Going with your text :
"

the is alligned with relational and/or object-based development standards
"

The architecs have choosen for the object-based development standards. (As you wrote "or" in your sentence, I think this is allowed). They are using a lot of Scott. W. Ambler texts. As I understood Ambler is one of the (or even the) guru's concerning OO.(http://www.ambysoft.com/mappingObjects.html)

So according to your writing we have to go with a standard. Within that standard we have to come up with solutions.

I think this is a 'valid' approach, but with this approach we 'run' into problems. Because the OO world and Relational world are (at least for a part) in conflict with each other. And I think my company is at the moment where we have to decide which rules we wil take from which world. (OO or Relational). The feeling exists that you cannot have both all the time. (If this is not a valid approach don't hesitate to point this out to me).

Accusing each other of incompetence does not bring a solution. (This wil end in a sort of religious war, where nobody wins. There have been enough discussions between OO and Relational guru's concerning this subject, by my knowledge this is still going on.) So I am trying to track down where 'conflicts' occur and try to find a solution for those situations within our organisation. Going from there you end up with solutions which do not satisfy all the rules or advises given in the OO world AND the Relational world.

As A relational 'boy' I did read some of the documents concerning OO. And picked out the parts which I think cause the most 'conflict' between OO and relational.

From just one document "Mapping Objects To Relational Databases" I have quoted some "rules" or texts at the end of this mail. But there are many more documents on OO.
If I understand the text correctly it writes do not use ANY propriety solutions.
(Triggers, Stored procedures and Sequences are mentioned as propriety, the concurrency mechanism is infered but not realy mentioned, but because there are different solutions within RDBMSses I assume they should be considered propriety as wel and therefore not be used. Even joins should not be used.).

For relational concepts, I like to go back to the texts and rules laid down by Cod and Date. (Date has given some answers to texts of Ambler, offcourse not agreeing with a lot of what Ambler
wrote.(http://www.pgro.uk7.net/cjd3a.htm)).

The choice for going OO is not a bad choice I think. (Because you mention it in your mail "object-based development standards ", the problem does not ly in the choice for OO).
But I am trying to hang on to 'most' Relational rules as wel, but I think concessions have to be made on both sides.

Thanks for your attention,
ben brugman

Some text of the one document by Scott W. Ambler, Quoted texts are literal. (Answers to some of this is given in the C.J.Date article)

In his texts Ambler writes :
"Proprietary Approaches Will Always Burn You"
---> And he describes not to use Sequences, Triggers and Stored Procedures, these are expliciet named.
"Logical Persistence Models Offer Little Value"
"most experience object mappers go straight from their OO models to their
physical persistence model."
"Many precepts of relational theory have proven disastrous in practice."
"Logical datamodelers. The reality is that there is no longer any need for
logical data models, other than perhaps for interim hand-holding of ......."
"Goes to show what data modelers know !"
"While I'm attacking the sacred values of DBSs everywhere,..."
"This issue was discussed previously, but the main conclusion was that
stored procedures are little better than a quick hack used to solve your short-term problems."
"Joins are Slow"
"Therefore don't do joins!"
"Because several small accesses are usallly more efficient than one big join
you should instead traverse tables to get the data." Received on Mon Oct 27 2003 - 08:50:31 CST