0 Replies Latest reply on Jul 22, 2002 2:17 PM by a13519

    store computed data or not?

    a13519

      Hello everybody,

      For almost one month I have been dropped in the thinking of architect of a application. (Broswer client, JSP/Servlet/J2EE server)In my case, there are several key points:

      1. There are 40 forms in the real world. The biggest form has 110 fields and average 50 fields in each form.
      2. This is not bad, the worst thing is the fields of about 20 forms among them related with other forms. Also, the different computation bind with each such fields. So there is a computation chain which consists of 350-400 fields computation, the precess must follow this order.
      3. Acutally, the original data (i mean the user inputed data) only occupy 20%-30% of the total fields.

      The goal of the application is to show the whole set of forms after the accurate computations. The usual design is to store the original data to database, then, once get a request from client, go through the whole computation chain to present a view to user(browser mode). In my view of this design, I think the performance will be very very bad. Because any small forms' view or any single change of the fields will cost whole computation chain's execution, server will be too busy to respond. My idea is to create table for all of the fields. When client ask a veiw it is very simple just querying; when client send a creation or updates, server depends on the location of the update to choose computation route, after process the affection table will be updated. My questions are:

      a. Is my idea a good? Or other approachs I should cosider?

      b. If I choose my plan, I have to face to build entity bean/DTO which has almost 100 fields. Is it will cause problem in implementation or performance?

      Any comments are very welcome!

      Thanks a lot!

      a13519