Most of these problems are solved if you simply use a real O/R tool such as CocoBase. Not only do we decouple the concrete object model from the concrete database model, but the mapping can be redone on the fly with recompiling or redeploying. And unlike the more limited and rigid code generation systems built into CMP servers, we actually provide this for CMP, BMP, Session, JSP or standalone compatible APIs.
CocoBase was built for this sort of task, and the Oracle Admin was right, that you shouldn't be limited to a CMP solution that's so rigidly bound to the database model. Tools like CocoBase let you have control over column names and and types, and they let you save objects to and from arbitrary table layouts. Not to mention that you also get value objects, dependent objects (not just dependent EJBs which are WAY to much overhead in complex fine-grained datasets), and the ability to serialize a complex object model in network call, basically work 'offline' on the local copy and simply 'saveState' with the root object when you're done... Too much emphasis is placed on trying to shoehorn CMPs rigidly that match the rdbms structure. It's not necessary, and usually just bad object modeling... If you want a solution that will make your life MUCH easier, just have a look at CocoBase (www.thoughtinc.com). It's available for a free download from the website, is pure java, integrates with most major IDEs, UML Modeling tools, App servers and is pure java. Have a look! It's what the EJB spec should support :) Ward Mullins CTO THOUGHT Inc. http://www.thoughtinc.com > Problem has very deep roots. When you know that some data model > changes will be in future, but don't know clearly what they will be > and application is enterprise level, sometimes it is very complicated > to alter a tables. What brings performance to go down an a lot of > other things. So it's very dangerous to have data model in database > tables. The one and only solution that i found is to have table views, > that separate different objects from data in object table. For > example: Object View Object(id, name, > type) -> Category(id, name), Subject(id, name) > > But for this to work, you must write triggers for insert, update and > delete actions on that view. The good thing is that you can assign > some attribute types to some object type in object-attribute table, > and after you should store attribute values in table like > AttrVal(attr_id, obj_id, value), you don't need alter table for adding > some type of attribute to object anymore. Any comments? > > > Mindaugas Kairys > ----- Original Message ----- > From: "Mike Bresnahan" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, April 17, 2002 5:40 AM > Subject: Re: 3rd normal form & EJB > > > > If I understand what you are asking, my recommendation to you is to > > not reimplement your data model in your application server. Your > > data model > has > > already been done for you in Oracle and you are not likely to > > improve on > it. > > Instead of modeling your data with EJBs, concentrate on modeling > > your application behavior. Object-orientation is a software design > > paradigm tuned for application design, not data modeling. > > > > Mike Bresnahan > > > > > -----Original Message----- > > > From: A mailing list for Enterprise JavaBeans development > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Mindaugas Kairys > > > Sent: Tuesday, April 16, 2002 3:59 AM To: > > > [EMAIL PROTECTED] Subject: 3rd normal form & EJB > > > > > > > > > Hello, > > > I have such philosophical, but real problem. My Oracle admin asks > > > me, > why > > > are you using such plane database design, what will you do, when > > > it will come the need for new object attributes: alter tables, > > > change program code, stop server....? > > > > > > I'd wanted to hear opinions, suggestions, the ways you solve that > problem > > > from you and ask what tools, tips, patterns one should use to > > > archieve database design of 3rd normal form normalization level > > > using EJB? I know that CMP entity EJB will be solution to achieve > > > that, but it takes too much time. Mhm... > > > > > > Mindaugas Kairys > > > > > > > > ====================================================================== > ===== > To unsubscribe, send email to [EMAIL PROTECTED] and > include in the body > of the message "signoff EJB-INTEREST". For > general help, send email to > [EMAIL PROTECTED] and include in the > body of the message "help". > > > ====================================================================== > ===== To unsubscribe, send email to [EMAIL PROTECTED] and include > in the body of the message "signoff EJB-INTEREST". For general help, > send email to [EMAIL PROTECTED] and include in the body of the > message "help". > > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
