'Lookup' table design decisions - Entity bean designs?


EJB design: 'Lookup' table design decisions - Entity bean designs?

  1. I am looking for different perspectives on how to implement entity beans when there are 'lookup' tables. For example, say I have an application where users in branches log customer enquiries for further followup. Hence I may have two tables, an Enquiry table which stores customer details and a Branch table which just stores Branch details.


    Hence in this case, the Branch table is a lookup table and the Enquiry table contains a foreign key which references the Branch table. Thus the Branch table is essentially static and read only. The Enquiry table is very dynamic - lots of reads/writes.

    Note I'm also focussing on EJB1.1 and BMP.

    Hence if I have an Enquiry entity bean - what if I want a method like enquiry.getBranch(). I might even want enquiry.getBranch().getName() etc.

    Any perspectives greatly appreciated...


  2. We had cached the static data in the hash table. Hash table key will be the primary key of the table (Branch Id in your case) and hash table element will be a branch object containing other fields(In your case Branch name...). This hash table will be loaded using JDBC when the server starts up (one less entity bean). We had no problems using this approach on Weblogic 6.0.

    Alternatly, on weblogic, you can use read only enity beans. This might improve the performance.