Hi, thank you for all your feedback. The approach with a custom persistance broker sounds good to me. I will try this.
My database (Oracle 9i) does handle the foreign key relations well, but it needs significantly more time. The lookup of a single text is not the problem. But when we select hundreds or thousands of records with one or more references to texts, the performance penalty sums up quickly. Lots of thanks Claus Am Di, 2003-12-09 um 07.57 schrieb Thomas Mahler: > Hi Claus, > > Claus Radloff wrote: > > Hi, > > > > when we started, we had two distinct tables, but this solution was too > > slow, as we have a few hundred thousand texts. So we put our texts in > > one table. This improved the performance significantly. > > Hmm, a decent database should be able to handle a foreign key relation > between two tables well, even with miliions of records. > I would never compromise a clean database model in such a case! > > > > > Wouldn't be a mechanism to allow people to provide their own storage > > classes be of general interest? Or am I the only one with such > > unorthodox constructs? > > You are the first requesting such a beast. I can imagine that there are > very special cases where it makes sense to allow users to provide their > own persistence mechanim. But as of today we did not see a general need. > > But adding this would require some in depth analysis of the OJB codebase > to find the best point of attack. > > For the time being OJB offers other solutions: > you can define stored procedures in the database to load all required > for your objects and in the repository_user.xml you can declare which > stored procedure to use for which class. > > Another solution thats already existing: You can implement your own > SqlGenerator component. going this way you have full control over the > sql generation. > > Then on the next level you could also provide your own PersistenceBroker > implementation... > > > With such a mechanism, one could also store/retrieve data from ldap or > > plain files etc. > > SOunds interesting but it would require us to implement a two phase > commit mechanism into the PersistenceBroker to cleanly handle the > transactions against diffent target systems. > > AT some point in time we decided to have a PersistenceBroker work > agaisnt one and only one target system during one transaction. > > So our approach is to implement dedicated PersistenceBrokers (one for > LDAP, one for flat-file...) > > cjeers, > thomas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
