--- Pablo Schor <[EMAIL PROTECTED]> wrote: > I'm trying to set up a many-to-many relation with > cmp and XDoclet, and what do I find in the XDoclet > web-site best practices ? "Try to avoid compound > primary keys".
EJB is really poor choice for complex data structures... ( I mean entity beans )... And CMR stuff in EJB 2.x ought to be prohibited by law... There are better alternatives, but banking environment is not the best place to make experiments. > I've been working in banking software for more than > 16 years, and 90% (or maybe more) of the keys I've > used have lots of fields. I thought we were > developing professional applications. How can I > avoid using compound keys? Well, 16 years ago you programmed plain sql or whatever. Now you still stuck with legacy applications, deployment cycles ( and costs ), operating departments or whatever. Inertia is really big. And I also used to work in banking environment. And there were legacy systems in production - moved a lot of money around, worked stable... But there were tables with 80 columns, and they placed ternary assotiations in 27 of them ( gosh, they used 27 columns to map kind of banknotes ( for example pounds ) to available denominations... ) And 2001 the finally needed 28th column. Because of turk lira, which got a billion note... This was not funny... And AFAIK never solved. regards, > Even the simplest entity, the customer, has a > compound key: document type and document number (and > sometimes more fields). What should I say to my > users? We would rather use a single field > customer_id because of technical reasons? I would avoid using natural keys as primaries. My choice is surrogates without any business meaning. > I don't know if this is a Xdoclet, EJB, J2EE, > containers or whatever issue, I think people > defining standards have to get closer to real > business solutions. I would say this is issue with entity beans. So, blame SUN, and whoever sits in JSR commitee... Really good alternative for your persistence problems is hibernate ( www.hibernate.org ), which is by chance supported by xdoclet, integrates with session beans if you need it, and has really good performance ( comparabvle with hand coded jdbc ) And please do not try to model attribute map ( string key, string value ) with entity beans... ===== ----[ Konstantin Pribluda ( ko5tik ) ]---------------- Zu Verst�rkung meines Teams suche ich ab Sofort einen Softwareentwickler[In] f�r die Festanstellung. Arbeitsort: Mainz Skills: Programieren, Kentnisse in OpenSource-Bereich ----[ http://www.pribluda.de ]------------------------ __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
