Struts database result set storage structure
Hi all. I am working on a struts application that will return results from a database. The question that I am currently uncertain of is how I should be storing the information from the database. I had thought about using a datastructure to store all of the results and then realized that would be unrealistic given the possible result size. I have instead decided to store only the items that will be displayed on the page. I just wanted to see if this seems like a reasonable idea, given that most people find what they are looking for on the first page or two. Any other thoughts on this would be appreciated.
[618 byte] By [
Aknibbsa] at [2007-10-3 4:48:06]
> Hi all. I am working on a struts application that
> will return results from a database. The question
> that I am currently uncertain of is how I should be
> storing the information from the database. I had
> thought about using a datastructure to store all of
> the results and then realized that would be
> unrealistic given the possible result size.
So you actually plan to send an HTML with 200,000 rows to the user? Get a smaller result and store it in the Session.
> > Hi all. I am working on a struts application that
> > will return results from a database. The question
> > that I am currently uncertain of is how I should
> be
> > storing the information from the database. I had
> > thought about using a datastructure to store all
> of
> > the results and then realized that would be
> > unrealistic given the possible result size.
>
> So you actually plan to send an HTML with 200,000
> rows to the user? Get a smaller result and store it
> in the Session.
No that's why I was thinking of using a resultset in the Session. I am guessing that I'll need to do profiling in order to determine the size that I will use. I was thinking of using between 20-50 results per page, leaning more heavily to the 20 - does that sound reasonable ?
> No that's why I was thinking of using a resultset in
> the Session. I am guessing that I'll need to do
> profiling in order to determine the size that I will
> use. I was thinking of using between 20-50 results
> per page, leaning more heavily to the 20 - does that
> sound reasonable ?
Yes, but why pass that result set around for that? It only might give you problems because you can't close the statement that created it without passing that around as well. If you close either at all. Also, a JSP should never have to deal with DB access. It's just supposed to display data, not to retrieve it.
> > No that's why I was thinking of using a resultset
> in
> > the Session. I am guessing that I'll need to do
> > profiling in order to determine the size that I
> will
> > use. I was thinking of using between 20-50
> results
> > per page, leaning more heavily to the 20 - does
> that
> > sound reasonable ?
>
> Yes, but why pass that result set around for that? It
> only might give you problems because you can't close
> the statement that created it without passing that
> around as well. If you close either at all. Also, a
> JSP should never have to deal with DB access. It's
> just supposed to display data, not to retrieve it.
I guess I should have been more explicit. I will be passing around 20-50 results stored in their own datastructure. I was using the word resultset but should have instead been using simply result. Thanks for the info.
Okay then. Anyway, why is this a profiling issue? How many results you deliver per page should solely be defined by ergonomic reasoning. What good is it to have yout DB perform well if the users won't touch your app because they get flooded with information? 50 rows is a lot already.
If you think it hits your DB too badly, you can pre-fetch more rows and cache them and only deliver a subset to the JSP. And/or let the JSP choose from the subset using passed-along begin and end indices.
> Okay then. Anyway, why is this a profiling issue? How
> many results you deliver per page should solely be
> defined by ergonomic reasoning. What good is it to
> have yout DB perform well if the users won't touch
> your app because they get flooded with information?
> 50 rows is a lot already.
That is why I was leaning more heavily to 20 results per page. Just thought I would get a couple other people's experiences as there is no standard it is simply based on "is your app relatively easy to use"
>
> If you think it hits your DB too badly, you can
> pre-fetch more rows and cache them and only deliver a
> subset to the JSP. And/or let the JSP choose from the
> subset using passed-along begin and end indices.
Ps. sorry about the confusion on my not using precise explanations as to what I was trying to accomplish.
